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EXECUTIVE  SUMMARY 


A.  TNTRODUCnON 

The  National  Test  Bed  (NTB)  Security  and  Communications  Architecture  Working  Group 
(SCAWG  -  also  called  the  "Tiger  Team")  has  developed  this  report  to  provide  definition  of  a 
system  architecture,  operational  concept,  and  system  implementation  approach  for  a  secure  and 
integrated  information  transfer  system  to  support  the  NTB  mission.  This  new  system  will  evolve 
from  the  existing  National  Test  Bed  Network  (NTBN). 

The  Tiger  Team  began  its  work  in  March  1991  and  met  regularly  for  five  months.  Initial 
Tiger  Team  efforts  focused  on  identifying  system  requirements  and  investigating  available 
technologies  in  the  areas  of  security,  automated  information  systems  (AIS)  interfaces, 
communications,  and  control.  The  Tiger  Team  evaluated  alternative  architectures,  operational 
concepts,  and  implementation  approaches  based,  on  their  projected  cost  and  responsiveness  to 
system  requirements.  The  Tiger  Team's  recommendations  were  approved  by  representatives  of  the 
Government  organizations  and  support  contractors  identified  in  Table  EX-1. 

Table  EX-1.  Tiger  Team  Representation 


Government 

Member 

Support 

Contractor 

SDIO/POl 

BDM  International,  Inc.  (BDM) 

SDIO/SIS* 

Beta  Analytics,  Inc.  (BAI) 

SDIO/SDA* 

General  Electric  (GE) 

SDIO/SDT 

MITRE 

(NTBJPO) 

Martin  Marietta 

USASDC 

COLSA,  INC. 

NSA 

SPARTA 

*  Government  representative  not  available 


B.  THE  rHAT.T.HNGE  AND  COMPELLING  NEED 

The  need  for  security  in  the  NTB  environment  is  dictated  by  the  sensitivity  of  information 
and  the  internal  and  external  threat  of  compromise  of  that  information.  Security  as  such  is  an 
enabling  technology  which  provides  a  wide  range  of  users  access  to  shared  computer  and 
communication  resources  which  process  information  at  multiple  levels  of  classification.  The 
challenge  in  providing  the  needed  security  is  defined  by  the  environment  within  which  the  NTB 
mission  must  be  performed.  The  key  elements  of  the  mission  environment  include: 


(1)  Dispersed  geography  with  many  AIS  platforms  and  many  requirements  to 
communicate; 

(2)  A  wide  range  of  users  from  Government,  industry,  and  various  U.S.  Allies;  and 

(3)  A  wide  range  of  security  classification  levels  required. 

In  order  to  accomplish  the  mission  within  this  operational  environment,  certain  fundamental 
components  of  infrastructure  must  be  implemented  in  an  integrated  manner.  These  include 
communications  and  control,  security,  and  AIS  interfaces.  These  components  provide  the  enabling 
technologies  needed  to  support  secure  information  exchange  among  the  broad  and  dispersed  NTB 
user  community.  The  interaction  among  these  components  of  infrastructure  demands  that  an 
integrated  approach  be  utilized  in  defining  the  system  requirements  and  architecture. 

C.  REQUIREMENTS 

The  derivation  of  security  and  communications  requirements  was  approached  from  a 
mission  perspective  as  well  as  user  (i.e.  SDIO  organizations  and  associated  contractors  that  need 
secure  communications  services  (NTBN)  to  perform  experiments  and  testing)  and  operator  (i.e.  the 
builders  and  maintainers  of  the  NTBN)  perspectives.  Examination  of  die  mission  drove  the 
derivation  of  fundamental  requirements  for  security  and  communications  infiiastructure,  while  the 
compilation  of  user  and  operator  views  of  requirements  either  validated  or  refined  the  fundamental 
mission-driven  requirements. 

The  NTBN  infrastructure  must  exhibit  certain  system  security  and  communications 
characteristics  in  order  to  be  responsive  within  the  research  and  development  environment.  The 
critical  characteristics  are  flexibility  (including  growth  capability),  modularity,  and  standardization. 
The  requirement  for  flexibility  is  derived  ft-om  both  the  changing  mission  environment  and  the 
evolution  of  test  phases  as  cited  by  the  SDIO  user  community.  The  requirement  for  modularity 
follows  the  derivation  of  the  requirement  for  flexiWlity,  and  the  need  to  suj^rt  a  shared  resource 
user  community.  The  need  for  standardization  (and  conform^ce  to  a  guiding  Mt  of  standards) 
derives  from  the  dynamic  nature  of  the  NTBN  user  community  and  from  public  law  and  DoD 
policy.  Standardization  of  security  access  mechanisms,  communications  mechanisms,  and 
operational  procedures  will  be  essential  to  maintaining  a  responsive  NTBN  over  its  life  cycle. 

Access  to  data  on  the  NTBN  must  be  restriaed  to  only  those  users  who  are  appropriately 
authorized  for  that  data.  Authorizations  should  be  based  on  a  user’s  security  clearance,  need  to 
know,  and  restrictions  resulting  from  organizational  conflicts  of  interest 

The  user  communications  requirements  presented  in  Annex  1  to  this  report  were  examined 
in  aggregate  for  trends  which  may  influence  the  system  architecture.  Validation  of  these  data 
through  interviews  with  SDIO  personnel  could  result  in  minor  changes.  However,  the  data  are  not 
expected  to  change  enough  to  affect  the  general  conclusions  drawn  from  the  data.  The  most 
obvious  conclusion  which  can  be  drawn  fiom  examination  of  the  requirements  data  is  that  there  is  a 
large  and  diverse  community  requiring  access  to  NTB  resources.  Furtfier,  this  diverse  community 
requires  NTB  assets  for  performing  many  different  types  of  functions  with  varying  levels  of 
security  requirements  and  data  rates.  One  also  notes  that  requirements  change  (sometimes 
significantly)  over  time.  All  of  these  factors  validate  Ae  secure  communications  requirements  of 
flexibility,  modularity,  and  standardization. 

The  consolidated  communications  requirements  data  show  a  large  concentration  of  user 
requirements  originating  from  Ae  Strategic  Defense  Dq)utate  (SD).  The  user  survey  also  mAcated 
a  requirement  for  over  40  T1  communications  links.  As  Aese  data  are  validated,  and  as  Theater 
Missile  Defense  (TD)  user  requirements  are  defined,  however,  boA  Ae  size  and  origin  of  NTBN 


user  requirements  could  change  significantly.  Thus  it  is  essential  that  the  ITTBN  have  a  modular 
arehitccture  to  allow  for  m'dular  growth. 

D.  RECOMMENDED  NTBN  ARCHITCCTURE 

1.  Introduction 

In  defining  a  responsive  NTBN  communications  and  security  architecture,  a 
comprehensive  examination  of  feasible  architectural  alternatives  was  conducted-  The  architectural 
alternatives  were  driven  by  the  compiled  functional  requirements.  The  global  set  of  alternatives 
may  be  categorized  within  two  areas:  (1)  multiple,  single  level  networks,  or  (2)  a  single, 
multilevel  secure  network.  Given  that  the  NTB  has  requirements  to  provide  processing  and  data 
storage  for  users  who  do  not  all  have  the  same  access  requirements,  the  NTBN  must  provide 
assured  separation  of  user  data  on  the  network.  This  can  be  ^vided  for  by  cither  of  the  two  types 
of  architectures.  The  overall  tradeoff  of  the  two  architectures  is  driven  by  responsiveness  and  cost. 

The  NTB's  current  configuration  consists  of  several  independent  networks.  Some 
networks  are  unclassified;  the  others  operate  cither  in  a  Dedicated  or  System  Hi^  mode  with  users 
cleared  to  the  highest  level  of  data  processed  on  the  network.  The  requirements  analysis 
documented  in  Armex  1  of  this  report  supports  the  need  for  several  additional  single-level  networks 
in  order  to  serve  the  needs  of  the  NTB's  users. 

As  an  alternative  to  the  proliferation  of  multiple,  single  level  networks,  a  single, 
multilevel  secure  (MLS)  network  could  be  employed  to  supper  the  NTB  users.  The  MLS  network 
architecture  could  use  a  single  network  backbone  to  provide  services  to  users  with  different 
clearances,  need  to  know,  and  corporate  affiliations. 

2.  Architecture  Selection 

Following  a  thorough  review  of  the  technology  options  available  for  meeting 
NTBN  communications  and  security  requirements,  the  Tiger  Team  concluded  that  establishment  of 
MLS  networks  is  now  a  realistic  alternative  to  the  continued  proliferation  of  the  single-level 
networks.  The  decision  to  recommend  an  MLS  NTBN  architecture  was  toven  by  several  key 
factors.  First,  it  will  be  prohibitively  expensive  over  the  long  term  to  duplicate  commurucations 
and  processing  systems  for  NTB  users  who  have  different  data  access  privileges  based  on  their 
clearance  level,  need-to-know,  and/or  corporate  affiliation.  Second,  single-level  netwo^s  cannot 
efficiently  support  the  future  operational  needs  of  the  diverse  SDI  user  community.  Finally,  the 

.  a  result  of  recent 


Chapter  VI  and  Appendix  A  of  this  report  summarize  the  Tiger  Team’s  evaluation 
of  the  following  alternative  architectures  for  a  secure  NTBN: 

(1)  Architecture  1.  This  approach  uses  secure  routers  to  connect  MLS  LANs  to  a 
communications  network  secured  by  1^  encryption  devices.  The  MLS  LANs  use  cominercially 
available  network  interface  units  and  control  processors  to  meet  NTBN  communications  and 
security  requirements. 

(2)  Architecture  2.  This  approach  employs  the  Government-developed  BLACKER 
Front  End  (BFE)  or  CANEWARE  Front  End  (CFE)  devices  as  the  interface  between  single-level 
LANs  (or  hosts)  and  a  packet  switched  network.  BFE  and  CFE  systems  provide  Type  1 
encryption  as  weU  as  conq)uter  security  features. , 


components  of  a  first-generation  MLS  network  are  now  commercially  avaiiaoie  as 
industry  and  Government-sponsored  product  development  and  evaluation  efforts. 


(3)  Architecture  3.  This  approach  combines  the  security  and  communications  features 

of  Architecture  1  and  Architecture  2.  BFE/CFE  devices  provide  a  packet  switched  network 
interface  for  MLS  LANs  as  well  as  single- level  LANs,  and  routers  provide  point- to-point 
interfaces  between  MLS  LANs.  ^ 

(4)  Architecture  4.  This  approach  uses  multiple  single-level  networics  to  enforce  data 
security. 


The  Tiger  Team  compared  the  candidate  architectures  on  the  basis  of  compliance 
with  networking  standards,  security  features,  communications  performance,  operational 
responsiveness,  and  cost  T^e  Tiger  Team  ruled  out  architectures  based  on  proprietary  products  or 
protocols  in  favor  of  a  multi-vendor  network  environment  based  on  DoD  implementation  of  open 
system  stand^ds.  With  this  approach,  the  NTBN  will  benefit  firom  the  wide  range  of  new  security 
and  co^unications  technologies  which  will  emerge  as  both  industry  and  Government  continue 
their  migration  toward  open  system  standards. 

The  Tiger  Team  concluded  that  Architecture  4  is  least  responsive  to  test  operations 
withm  an  R  &  D  environment  because  reliance  on  multiple,  independent  networks  can  prevent 
efficient  mfotmation  transfer  among  AISs  connected  to  different  networks.  In  addition,  the  overall 
cost  of  this  approach  rapidly  increases  as  data  security  classification  levels  and  other  access 
restrictions  are  expanded.  The  limitation  of  Architecture  2  and  Architecture  3  is  the  slow 
communications  throughput  of  the  BFE  devices.  When  Caneware  network  interfaces  are  available, 
acceptable  throughput  will  be  achievable  from  these  architectures. 

^  The  Tiger  Team  selected  Architecture  1  as  its  near-term  architecture 
recommendation  because  it  provides  high  communications  throughput  and  can  be  implemented 
now  using  commercial  products  which  use  open  systems  protocols. 

3.  Architecture  Implementation  Phasing 

Although  Architecture  1  is  the  recommended  approach,  in^lementation  flexibility  is 
maintained  by  sequencing  a  prototype  acquisition  phase  that  begins  at  the  LAN  level  and 
pro^sses  up  through  the  router/gateway  level  to  the  backbone  network  level.  In  this  manner,  the 
option  would  be  retained  to  migrate  to  Architecture  3  at  the  router/gateway  level  should  future 
commercial  and  Government  developments  merit  this  approach. 

E.  SYSTEM  IMPLEMENTATION  PHASING  OVERVIEW 

The  proposed  three-part  phasing  of  the  MLS  implementation  is  shown  in  Figure  EX- 
L  The  near-term  91-93)  and  mid-term  (IT93-95)  phases  provide  for  NTBN  upgrading  to  an 
initial  MLS  capability.  The  long-term  (FY95-99)  phase  involves  incorporation  of  features  for 
increasing  MLS  security  assurance. 

In  comparing  NTBN  security  goals  and  r^uirements  to  predicted  technological 
advances,  great  care  was  ^en  to  be  realistic  and  objective.  It  is  anticipated  tiiat  the  National 
Security  Agency  (NSA)  will  continue  to  place  high  priority  on  evaluating  an  even  greater  number 
of  Computer  Security  (COMPUSEC)  products  at  even  higher  levels  of  COMPUSEC  trust  in  the 
years  ahead.  Increased  assurance  of  secure  operation  is  gained  as  products  evaluated  at  higher 
levels  of  COMPUSEC  trust  are  incorporated.  The  increased  assurance  is  indicated  by  upgrading 
from  a  B3  level  of  trust  to  an  A1  level.  (B3  and  A1  are  the  techiucal  terms  used  by  the  NSA  and 
DoD  to  indicate  the  degree  of  trust  (i.e.  assurance  of  secure  operation)  t^t  a  coneputer  system  has 
achieved.)  A  system  accredited  at  the  A 1  level  incorporates  security  products  and  safegua^  that 
offer  significantly  higher  levels  of  trust  than  those  needed  for  B3  accreditation.  The  NTBN  must 
have  the  highest  ^ssible  degree  of  trust  to  minimize  the  risk  of  security  conq)romise.  Therefore,  a 
phased  approach  is  recommended  to  achieve  higher  levels  of  assurance  as  the  technology  becomes 
available. 
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Figure  EX-1.  Implementation  Program  Overview 


F.  CONCLUSIONS 

This  report  recommends  a  multilevel  secure  architecture  to  meet  the  SDI  community's  need 
for  a  data  transfer  network  which  can  restrict  user  access  to  data  based  on  a  range  of  security 
considerations  including  clearance  level,  need-to-know,  citizenship  status,  and  corporate 
affiliation.  The  recommendation  was  driven  by  three  key  factors.  First,  a  cost  analysis  showed 
that  it  will  be  prohibitively  expensive  over  &e  long  term  to  duplicate  communications  and 
processing  systems  for  each  set  of  NTBN  users  who  arc  not  allowed  access  to  the  existing  set  of 
single-level  networks.  Second,  the  proliferation  of  single-level  networks  will  adversely  affect 
operation  by  forcing  some  users  to  rely  on  two  or  more  networks  to  perform  a  task  which  could 
more  efficiently  be  performed  on  a  single,  integrated  network.  Finally,  a  technology  survey 
showed  that  components  of  a  first-generation  MLS  network  are  now  commercially  available  as  a 
result  of  recent  industry  and  Government-sponsored  product  development  and  evaluation  efforts. 

The  recommended  NTBN  architecture  meets  user  requirements  identified  in  this  report  and 
provides  a  basis  for  modular  and  flexible  growth  to  accommodate  new  requirements  and 
technologies  as  they  are  identified.  The  selected  architecture  includes: 

(1)  A  LAN  component  which  conforms  to  the  DoD  standard  protocol  suite  and 
suppeuts  secure,  high-speed  communications  with  single  or  multilevel  hosts. 


(2)  An  Internet  component  consisting  of  secure  routers/gateways,  which  support  the 
DoD  protocol  suite  and  secure,  high-speed  communications  with  single  or 
multilevel  hosts. 

(3)  A  WAN  backbone  which  supports  the  DoD  protocol  suite  and  secure 
interconnection  of  NTBN  nodes  through  the  LAN  and  Internet  components. 

The  Tiger  Team's  recommendations  for  implementing  the  recommended  architecture 
include: 

(1)  Completing  the  systems  engineering,  design  and  planning  acdvides  required  to  gain 
management  approval  for  procuring  MLS  networking  components. 

(2)  Installing  a  first- generation  MLS  network  in  FY-92  and  performing  proof-of- 
concept  testing  of  key  elements  of  the  recommended  architecture  and  detailed 
network  design. 

(3)  Establishing  DAA  MOAs  to  encompass  responsibilities  and  security  policies  for 
protection  of  classiEed  information  on  AISs  and  the  NTON. 

(4)  Establishing  an  NTBN  configuration  control  board. 

(5)  Beginning  a  follow-on  effort  to  define  an  approach  for  providing  trusted 
workstations  and  hosts. 
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I.  INTRODUCTION 


The  National  Test  Bed  (NTB)  Security  and  Communications  Architecture  Working  Group 
(SCAWG  -  also  called  the  'Tiger  Team")  has  developed  this  repon  to  provide  definition  of  a 
system  architecture,  operational  concept,  and  system  implementation  approach  for  a  secure  and 
integrated  information  transfer  system  to  support  the  NTB  mission.  This  new  system  will  evolve 
from  the  existing  National  Test  Bed  Network  (NTBN). 

The  report  consists  of  eight  sections:  Section  I,  Introduction,  defines  the  scope  and 
objectives  of  the  Tiger  Team  effort  reported  herein,  as  well  as  providing  background  on  the 
evolution  of  the  NTBN  security  and  communications  architecture  development  Section  II 
provides  a  set  of  basic  working  definitions  used  throughout  this  report  Section  HI  provides  an 
explanation  of  the  challenge  and  compelling  need  for  an  integrated  security  and  communications 
architecture.  Section  IV  presents  the  consolidated  NTBN  requirements  derived  from  an  analysis  of 
the  NTB  mission  and  interviews  with  SDIO  personnel.  Section  V  describes  the  basic  concepts  and 
technologies  available  to  suppon  an  integrate  security  and  commuiucations  architecture.  Section 
VI  provides  a  system  description  of  the  recommended  security  and  communications  approach  and 
is  con^rised  of  an  operational  concept  and  companion  NTBN  security  and  commuiucations  system 
architecture.  Section  Vn  describes  system  implementation  tasks  including  recommended  phasing 
of  the  required  work.  Section  Vin  presents  the  Tiger  Team's  conclusions  and  siunmary 
recommendations.  Appendix  A  -  Arcititecture  Evaluation  provides  detailed  information  which 
supports  the  system  description  presented  in  Section  VI,  Appendix  B  -  Guidance  and 
Requirements  Document  provides  preliminary  architectures  and  requirements  for  evolution  to  the 
MLS  NTB  Commuitication  and  Computing  System,  and  Appendix  C  provides  a  glossary  of  terms 
used  in  this  report  Two  annexes  are  available  from  SDIO^’OI  upon  request:  Annex  1  provides  a 
compilation  of  user  requirements,  and  Annex  2  provides  a  compilation  of  ciurent  and  future 
products  which  will  support  implementation  of  the  recommended  architecture. 

A.  Scope  and  Objectives 

This  document  provides  a  description  of  an  NTBN  security  and  commuiucations 
architecture,  op^tional  concept  and  system  implementation  approach  which  is  intended  to  assist 
in  planning  and  implementation  of  a  responsive  and  secure  NTB  information  transfer  systenx  In 
ad^tion,  representative  costing  information  is  provided  to  assist  in  financial  plamiing. 

B.  Background 

The  Tiger  Team  is  an  interim  working  group  formed  to  define  an  integrated,  secure 
information  transfer  system  to  support  the  NTB.  llie  team  comprises  the  goveriunent  members 
and  support  contractors  identified  in  Table  M. 

Table  I- 1.  Tiger  Team  Representation 


Gov«rnment 

Member 

Support 

Contractor 

SDIO/POl 

BOM  International.  Inc.  (BOM) 

SDIO/SIS* 

Beta  Analytics,  Inc.  (BAI) 

SDIO/SDA* 

General  Electric  (GE) 

SDIO/SDT 

MITRE 

(NTBJPO) 

Martin  Marietta 

USASDC 

COLSA,  INC. 

NSA 

SPARTA 

•  Government  representative  not  available 


The  group  has  met  on  several  occasions  since  its  formation  in  March,  1991,  to  define  and  execute 
a  methodology  for  development  of  a  secure  information  transfer  system  for  the  NTB  which 
includes  the  implementation  and  integration  of  the  key  enabling  technologies  of  security,  AIS 
interfaces,  and  communications  and  control . 

The  Tiger  Teain  was  formed  as  a  logical  successor  to  the  NTB  Security  Strategy 
Working  Group  (NSSWG)  which  developed  the  security  development  methodology  and  produced 
a  report  which  included  a  strawman  architecture,  and  the  guiding  security  policy  for  the  NTB.  The 
NSSWG  provided  a  substantial  step  forward  by  identifying  security  as  an  enabling  technology 
which  must  be  integrated  with  AIS  interfaces,  communications  and  control  in  order  to  provide  the 
infrastructure  necessary  to  support  the  NTB  mission.  The  Tiger  Team  has  incorporated  the 
products  of  the  NSSWG  work  within  its  approach  and  has  provided  the  necessary  integration  of 
these  elements. 


The  Tiger  Team  has  defined  a  top-down  development  approach  to  ensure 
compilation  and  integration  of  NTB  mission  requirements  and  timely  development  and 
implementation  of  a  responsive  NTBN  architecture.  The  approach  con:q)rises  four  primary  phases: 

(1)  Compile  functional  communications  and  security  requirements  based  on 
examination  of  the  NTB  operational  environment  and  on  various  users’  and 
operator's  perceptions  of  information  transfer  requirements  to  suppon  the  NTB 
mission; 

(2)  Compile  applicable  communications  and  security  technologies  that  would  support 
architecture  definition; 

(3)  Develop  a  communications  and  security  architecture  and  operational  concept  which 
builds  upon  the  NSSWG  work  which  has  been  done,  and  also  incorporates 
consideration  of  the  compiled  requirements  and  available  technologies;  and 

(4)  Develop  a  phased  implementation  plan  which  provides  a  migration  strategy  for 
achieving  the  NTB  security  and  communications  goals. 

The  first  two  phases  of  the  Tiger  Team  approach  were  executed  concurrently  by  a 
requirements  subgroup  and  a  technology  subgroup,  each  of  which  comprised  a  cross-section  of  the 
Tiger  Team  members.  The  results  of  the  four  phases  are  presented  in  this  report. 

C.  Rsfsrencss 

(1)  NTBN  Draft  Requirements  Report,  May  10, 1991 

(2)  NSSWG  Draft  Final  Report,  March  4, 1991 

(3)  DoD  Directive  5200.28,  Security  Requirements  for  Automated  Information 
Systems,  March  21, 1988 

(4)  DoD  Standard  5200.28-STD,  Department  of  Defense  Trusted  Computer  System 
Evaluation  Criteria,  December  1985 

(5)  National  Computer  Security  Center  Guidelines,  NCSC-TG-XXX  (also  referred  to 
as  the  "Rainbow  Series") 
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II.  WORKING 


»jsiaiciiiwci 


In  order  to  provide  the  mechanism  to  ensure  the  consistent  presentation  of  ideas,  certain 
generally  used  terms  were  given  strict  definitions.  These  definitions  are  entirely  consistent  with 
those  used  by  the  NSSWG,  and  will  continue  to  be  used  in  all  SCAWG  efforts. 

( 1 )  National  Test  Bed  (NTB) 

The  Automated  Information  Systems  (AIS)  equipment,  and  its  environment, 
that  is  used  to  support  the  SDIO  research  and  development  (R&D)  effort.  TTie 
assets  may  be  connected  to  the  National  Test  Bed  Network. 

(2)  NTB  Network  (NTBN) 

The  Communication  and  control  medium  that  permits  connection  between 
NTB  AIS  assets.  (It  can  also  be  thought  of  as  being  bounded  by  the  last  electronic 
connection  of  any  NTB  AIS  that  can  communicate  with  other  NIB  AISs). 

(3)  NTBN  Node 

The  AIS  equipment  and  its  environment  at  a  particular  physical  location  that 
is  used  to  support  the  NTB  and  is  connected  to  the  NTBN.  (e.g.,  the  NTF  or 
SDC). 

(4)  National  Test  Facility  (NTF) 

The  AIS  equipment,  and  its  environment  at  Falcon  Air  Force  Base,  that  is 
used  to  support  the  NTB  (e.g..  Computer  Room  1  and  Directed  Energy  Suppon 
Center,  which  arc  connected  to  the  NTBN).  (The  NTF  currently  acts  as  the  hub  for 
NTBN  communications.) 

III.  THE  CHALLENGE  AND  COMPELLING  NEED 

The  need  for  security  in  the  NTB  operational  environment  is  dictated  by  the  sensitivity  of 
information  and  the  internal  and  external  threat  of  compromise  of  that  information.  Security  as  such 
is  an  enabling  technology  which  provides  a  wide  range  of  users  access  to  shared  computer  and 
communication  resources  which  process  information  at  multiple  levels  of  classification.  The 
challenge  in  providing  the  needed  security  is  defined  by  the  environment  within  which  the  NTB 
mission  must  be  performed.  Tlie  key  elements  of  the  mission  environment  include: 

(1)  Dispersed  geography  with  many  AIS  platforms  and  many  requirements  to 
communicate; 

(2)  A  wide  range  of  users  from  Government,  industry,  and  various  U.S.  Allies;  and 

(3)  A  wide  range  of  security  classification  levels  required. 

In  order  to  accomplish  the  mission  within  this  q)erational  environment,  certain  fundamental 
components  of  infrastructure  must  be  implement^  in  an  integrated  manner,  and  include 
communications  and  control,  security,  and  AIS  interfaces.  These  components  provide  the  enabling 
technologies  needed  to  support  secure  information  exchange  among  the  broad  and  dispersed  NTB 
user  community.  The  interaction  among  these  components  of  infrastructure  demands  that  an 
integrated  approach  be  utilized  in  defining  the  system  requirements  and  architecture. 
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IV.  REQUIREMENTS 


A.  Technical  Approach  for  Requirements 

The  derivation  of  the  security  and  communications  requirements  was  approached 
from  a  mission  perspective  as  well  as  user  (i.e.  SDIO  organizations  and  associated  contractors  that 
need  secure  communications  services  (NIEN)  to  perform  experiments  and  testing)  wd  operator 
(i.e.  the  builders  and  maintainers  of  the  NTBN)  per^ctives.  Examination  of  the  mission  drove 
the  derivation  of  fundamental  requirements  for  security  and  communications  infrastructure,  while 
the  compilation  of  user  and  operator  views  of  requirements  either  validated  or  refined  the 
fundamental  mission-driven  requirements. 

The  approach  for  compiling  user  and  operator  perspectives  of  functional 
communications  requirements  involved  two  views:  top-down  and  bottom-up.  The  top-down  view 
consisted  of  asking  managers  in  the  SDIO  community  to  identify  current  and  potential  future 
information  transfer  requirements  to  execute  the  various  levels  of  tests  required.  The  results  of 
initial  interviews  to  determine  the  high-level  or  top-down  view  of  requirements  were  presented  at 
the  April  8-9  Tiger  Team  Meeting,  and  are  contained  in  Annex  1.  Concurrent  with  this  effort,  the 
Requirements  Team  investigated  current  NTBN  utilization,  assuming  that  current  security  and 
communications  requirements  offer  a  useful  low-level  or  bottom-up  view  of  future  system 
requirements.  The  correlation  of  these  top-down  and  bottom-up  requirements  provide  a  set  of 
requirements  data  on  which  to  base  an  architecture  design.  From  the  bottom-up  view,  the 
Requirements  Team  obtained  current  and  projected  ITO  and  SDC  user  requirements.  From  the 
top-down,  two  views  were  compiled:  (1)  user  requirements  were  obtained  through  intCTviews 
with  SDIO^DN,  SDG,  and  TD;  and  (2)  GE  provided  the  SEIC  requirements  perspective. 

B.  Expected  Future  Use  of  Data 

In  order  to  take  full  advantage  of  the  requirements  data  gathered  for  this  effort,  an 
NTBN  User  Requirements  Database  has  been  created  by  SDIO/TOI.  This  database  contains  all  of 
the  pertinent  programmatic  data  derived  from  the  raw  data  provided  in  Annex  1.  Separate  entries 
are  TnaHff  for  each  test  function  identified  by  NTBJPO  and  USASDC.  Separate  entries  are  made 
for  each  test  concept  identified  by  SEIC.  All  of  these  entries  are  called  'SDS  Function'  in  the 
database.  For  each  SDS  Function,  the  following  data  are  provided  as  available: 

( 1 )  User  Organization; 

(2)  SDIO  Sponsor  (person); 

(3)  SDIO  Sponsor  Organization; 

(4)  Contract  Number, 

(5)  Contract  Type  (i.e.,  system/subsystem/clement;  technology;  or  other); 

(6)  User  Type  (i.e.,  administrative  data  exchange;  model  development/batch 

simulations;  or  interactive,  distributive  or  real-time  simulations/experiments); 

(7)  Node; 

(8)  Data  Rate;  and 

(9)  Security  Classification. 
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At  a  minimum,  the  database  allows  data  to  be  sorted  by  sponsor  organization,  user  type,  data  rate, 
Md  security  classification.  The  database  in  aggregate  form  provides  requirements  information  for 
initial  aichitectme  development.  The  database  will  be  maintained  with  current  data  ensuring  that 
the  NTBN  architecture  evolution  and  implementation  planning  can  be  driven  by  requirements. 

C.  Consolidated  NTBN  Requirements 

1.  NTB  Mission  Guidance 

The  NTB  mission  and  DoD  security  policy  directly  drive  the  general 
requirement  for  a  security,  communication,  and  AIS  interface  infrastructure.  The  original  NTB 
Charter  statement  dated  August  4, 1986  establishes  the  context  for  the  infrastructure: 

"Provide  the  comprehensive  capability  to  compare,  evaluate,  and  test  SDS 
architectures,  key  technologies,  and  BM/C?  strategies." 

Further  direction  by  President  Bush  in  late  1990  established  another  component  direction  to  SDIO 
regarding  the  OPALS  concept,  and  thus  implied  an  added  direction  for  the  NTB.  The  NTB 
mission  examined  in  light  of  the  environment  in  which  it  must  operate  quickly  identifies  three 
inqiortant  faaors: 

(1)  The  geographically  dispersed  nature  of  the  SDI  programs  is  also  reflected  in  the 
dispersed  nature  of  test  resources  and  users  and  will  continue  to  be  so  in  die  future; 

(2)  The  sensitive  and  classified  aspects  of  SDI  technology  and  research  must  be 
protected  from  unauthorized  access,  modification,  and  destruction;  and 

(3)  The  NTB  must  operate  in  a  common  or  shared  user  environment  which  includes 
participation  by  Government  organizations,  allied  nations,  and  multiple  contractors. 

A  restatement  of  these  factors  as  a  generalized  infrastructure  requirement  follows:  the  NTB  is 
required  to  provide  testbed  resources,  protected  from  unauthorized  use  or  intrusion,  with  user 
access  across  a  broad  geography  for  a  variety  of  Government,  contractor,  and  allied  nation  users. 

2.  System  Functionality 

In  support  of  the  SDI  mission,  the  NTB  goal  is  to  provide  a  common  test 
environment  for  the  design  of  SDS,  including: 

(1)  To  support  the  simulation  and  validation  of  SDS  elements  and  overall  system 
concepts; 

(2)  To  support  the  planning  and  conduct  of  system  element  and  overall  system  studies 
and  a^yses  that  are  excursions  from  the  baseline  SDS  concept; 

(3)  To  provide  supp^  to  USSPACECX)M  for  Concepts  of  Operations  (CONOPS)  and 
c^)erational  training; 

(4)  To  support  cocndinaticm  of  SDI  field  experiments  involving  multiple  elonents; 

(5)  To  support  establishment  and  maintenance  of  a  state-of-the-art  simulation  and 
analysis  c^ability  including  cotmectivity  anx>ng  NTBN  nodes; 
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(6)  To  provide  a  data  repository  for  all  SDIO  approved  models,  experiments,  and 
simulations; 

(7)  To  support  configuration  control  of  all  SDS  models  software;  and 

(8)  To  collect,  store,  and  provide  access  to  standard  SDI  threat  data. 

3.  System  Rgquircmggts 

The  NTBN  infrastructure  must  exhibit  certain  system  security  and 
communications  characteristics  in  order  to  be  responsive.  The  critical  characteristics  are  flexibility 
(including  growth  capability),  modularity,  and  standardization. 

The  requirement  for  flexibility  is  derived  ftom  both  the  changing  mission 
environment  and  the  evolution  of  test  phases  as  cited  by  the  SDIO  user  community.  The  mission 
environment  is  altered  by  the  redirection  of  SDIO  toward  theater  and  tactical  considerations  which 
in  turn  may  alter  the  required  geographic  dispersion  of  supporting  NTB  resources.  The  evolution 
of  test  phases  as  identified  in  interviews  with  SDIO/TD,  SDN,  and  SDG  indicate  that  most  of  the 
programs  in  SDIO  are  still  in  early  stages  of  development,  and  as  development  progresses  test 
complexity  and  scope  will  expand.  New  sites  may  be  added,  and  must  be  accommodated  by  the 
NTBN. 


The  requirement  for  modularity  follows  the  derivation  of  the  requirement  for 
flexibility,  and  the  need  to  support  a  shared  resource  user  conmunity.  WiA  a  dynamic  user 
community  accessing  a  shared  resource,  a  common  set  of  mechanisms  for  providing  Aat  access  is 
essential  for  system  responsiveness.  A  modular  approach  allows  the  system  to  easily  adapt  to 
varying  data  capacity  and  security  requirements,  inaking  resources  available  as  they  are  needed. 
Thus  modularity  is  a  critical  characteristic  that  must  be  incorporated  in  a  responsive  system 
architecture. 


The  need  for  standardization  (and  conformance  to  a  guiding  set  of 
standards)  derives  from  the  dynamic  nature  of  the  NTBN  user  community  and  from  public  law  and 
DoD  and  federal  policy.  Standardization  of  security  mechanisms,  communications  mechanisms, 
and  operational  procedures  will  be  essential  to  maintaining  a  responsive  NTBN  over  its  life  cycle. 
The  selection  of  a  guiding  set  of  standards  for  the  NTBN  ^hitecture  is  driven  by  this  need  for 
supponability  and  maintainability;  however,  it  is  also  recognized  that  standards  in  communications 
and  security  are  still  evolving  and  thus  the  NTBN  architecture  must  be  flexible  enough  to  evolve 
with  those  standards. 

4.  Security  Requirements 

Access  to  data  on  the  NTB  must  be  restricted  to  only  those  users  who  are 
appropriately  authorized  for  that  data.  Authorizations  shall  be  based  on  a  us^s  security  clearance, 
need-to-know,  and  restrictions  resulting  from  organizational  conflicts  of  interest  To  meet  the 
projected  user  requirements  and  to  enhance  the  current  capabilities,  the  NTB,  and  in  particular  the 
NTF  and  the  NTBN,  should  suppon  a  Multilevel  Secure  (^S)  mode  of  o^ration.  The  MLS 
requirement  is  directly  driven  by  the  NTB  system  requirement  to  "provide  a  common  test 
environment  for  the  design  of  SDS",  and  by  the  wide  participation  of  Government  academic, 
industry,  and  allied  nation  organizations. 

This  requirement  statement  is  in  general  supported  by  the  compil^  user 
requirements  which  reflect  many  spedflc  requirements  to  simultimeously  process  unclassified  to 
Secret  infonnation  and  in  a  few  cases  Secret  to  Top  Secret  information. 
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5.  Communicarions  Requirements 


The  NTB  user  communications  requirements  assembled  by  the  Tiger 
Team's  requirements  subgroup  and  presented  in  Annex  1  were  examined  in  aggregate  for  trends 
which  may  influence  the  system  architecture.  Validation  of  these  data  through  interviews  with 
SDIO  personnel  could  result  in  minor  changes.  However,  the  data  are  not  expect^  to  change 
enough  to  affect  the  general  conclusions  which  were  drawn  from  them.  In  addition  to  identifying 
overall  trends  in  the  requirements,  the  assembled  data  were  sorted  and  consolidated  with  respect  to 
four  key  categories  influencing  the  NTBN  architecture.  These  are:  sponsor  organization,  user 
type,  security  classification,  and  communications  requirements  (size  and/or  type).  Specific 
conclusions  drawn  from  this  consolidation  of  the  requirements  data  are  included  in  Annex  1. 

The  most  obvious  conclusion  which  can  be  drawn  from  examination  of  the 
requirements  data  is  that  there  is  a  large  and  diverse  community  requiring  access  to  NTB  resources. 
Further,  this  diverse  community  requires  NTB  assets  for  performing  many  different  types  of 
functions  with  varying  levels  of  security  requirements  and  data  rates.  <^e  also  notes  that 
requirements  change  (sometimes  significantly)  over  time.  All  of  these  factors  validate  the  system 
requirements  of  flexibility,  modularity,  and  standardization  outlined  earlier. 

The  NTF,  USASDC,  and  SEIC  ^uirements  data  can  also  be  assessed  with 
regard  to  the  High-Level  User  View  of  NTB  communications  requirements.  The  high  level  view 
was  compiled  tiirough  interviews  within  three  broad  categories  in  SDIO:  Strategic  Defense 
Deputate  (SD)  other  than  Brilliant  Pebbles,  Theater  Missile  Defense  Deputate  (TD),  and  Brilliant 
Pebbles  (BP)  activities.  The  compilation  of  these  user  views  indicate  that  there  are  three  general 
areas  of  communication  requirements  for  suppon  of  SDS  or  OPALS  tests  and  experiments: 

( 1 )  Simulation  to  simulation  communications,  primarily  within  a  single  node; 

(2)  Simulation  to  prototype  ccnomunications  across  a  broad  geography;  and 

(3)  Prototype  to  prototype  communications  across  a  broad  geography. 

Common  to  all  of  these  general  communications  requirements  is  the  need  to 
provide  access  to  a  wide  range  of  test  participants  and  users.  The  first  category  of  communications 
requirement  indicates  the  ne^  for  locd  node  communications  throughput  which  may  exceed  tens  of 
megabits  per  second,  depending  on  simulation  approach.  The  next  two  categories  indicate  an 
extension  of  this  throughput  requirement  to  intemode  communications  sometime  in  the  friture.  It 
should  be  noted  that  the  definition  of  these  requirements  was  at  a  more  advanced  stage  at  SD  than 
within  TD  or  BP. 


In  general,  it  appears  that  the  requirements  identified  in  this  effort  represent 
current  and  near-term  future  requirements,  which  explains  why  they  in  large  part  represent  non- 
Theater  Missile  Defense  (TMD)  and  non-Brilliant  Pebbles  functions.  This  conclusion  further 
emphasizes  the  dynamic  nature  of  the  NTB  communications  requirements,  and  thus  the  need  for  a 
flexible  and  modular  architecture,  as  well  as  the  need  to  complete  and  maintain  the  database  of  user 
requirements. 


The  consolidated  requirements  data  show  a  large  concentration  of  NTBN 
user  requirements  originating  from  the  SD,  but  with  all  current  intemode  throughput  requirements 
at  T1  rate  or  less.  As  these  data  are  validated,  and  as  TD  user  requirements  are  defined,  however, 
both  the  size  and  origin  of  NTBN  user  requirements  could  change  significantly.  Thus  it  is  essential 
that  the  NTBN  have  a  modular  architecture  to  allow  for  modular  growth. 
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V.  ENABLING  TECHNOLOGY 


This  section  provides  an  introduction  to  the  technologies  aud  products  which  provide  the 
basis  for  implementing  systems  meeting  the  requirements  defined  in  Section  IV.  Additional 
information  on  the  security  and  communications  concepts  introduced  below  may  be  found  in  the 
NSSWG  Final  Report.  Definitions  of  terms  may  be  found  in  the  glossary  and  are  consistent  with 
those  given  in  the  National  Computer  Security  Center's  (NCSC's)  "Rainbow  Series"  of 
publications.  Additional  data  on  available  products  is  presented  in  Annex  2  of  this  report 

A.  Security  and  Communications  Concepts 

The  material  in  this  paragraph  is  presented  as  background  to  assist  the  reader  in 
understanding  subsequent  discussions  of  technologies,  products,  and  system  architectures.  Figure 
V-1  is  a  generic  architecture  diagram  showing  multiple  nodes  interconnected  by  a  communications 
network.  The  node  defined  in  Figure  V-1  is  a  combination  of  hosts  and  LANs  located  at  a  si^cific 
site  and  connected  to  other  nodes  via  a  WAN.  Figure  V-2  identifies  four  categories  of 
hardware/software  products  used  in  the  generic  network  architecture.  Definitions,  examples  and 
security  concepts  for  these  four  product  categories  are  presented  below.  Examples  of  product 
categories  and  security  concepts  are  drawn  fi'om  the  existing  NTBN  architecture. 

1.  Host  Computers 

A  host  is  any  computer-based  system  connected  to  the  network  and 
containing  the  necessary  protocol  interpreter  software  to  initiate  network  access  and  carry  out 
information  exchange  across  the  network.  This  definition  encompasses  typical  "mainframe"  hosts, 
generic  terminal  support  machines,  and  workstations  connected  directly  to  the  communications 
subnetwork  and  executing  the  intercomputer  networking  protocols.  A  dumb  terminal  is  not  a  host 
because  it  does  not  contain  the  protocol  needed  to  perform  information  exchange;  a  workstation  is  a 
host  because  it  does  have  such  capability. 

Examples  of  host  computers  on  the  existing  NTBN  include  the  CRAY, 
VAX  and  IBM  mainframes  connected  to  the  classified  network  at  the  NTF  and  the  SUN 
workstations  which  provide  access  to  these  NTF  resources  from  each  NTBN  node.  All  hosts 
connected  to  the  NTBN  are  currently  accredited  to  process  data  at  a  single  classification  level 
(SECRET)  in  the  Dedicated  mode  of  operations  (see  Appendix  C  -  Glossary  for  definition). 
Security  features  currently  required  for  NTBN  hosts  are  identification  and  authentication  measures 
and  limited  audit  capabilities.  As  part  of  ongoing  efforts  to  upgrade  selected  host  processors  to 
System  High  accreditation,  operating  system  software  evaluated  by  the  NCSC  at  the  C2  (or  better) 
level  or  containing  equivalent  features  is  being  installed. 

2.  LAN  Components 

A  Local  Area  Network  includes  the  cable  plant,  interface  electronics  and 
associated  software  required  to  provide  network  services  to  LAN  users  in  a  single  building  or 
group  of  buildings  connected  primarily  by  local  (i.e.  not  long-distance)  communications  circuits. 
Figure  V-3  shows  that  each  of  ten  NTBN  nodes  has  an  Ethernet  LAN  which  connects  to  the 
NTBN  WAN  via  an  AIS  integration  component.  Some  nodes  (e.g.  SDC,  ESD)  have  adchtional 
LANs  connected  to  the  NTBN  via  AIS  Integration  Components.  Protected  cable  distribution 
systems  are  the  only  security  feature  currently  associated  with  NTBN  LAN  components.  Hosts 
connected  to  the  LAN  are  required  to  have  identification  and  authentication  measures  and  audit 
capabilities.  The  existing  LAN  interface  components  have  no  evaluated  security  features  and 
therefore  limit  the  LAN  to  the  dedicated  mode  of  operation. 
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NODE 


Figure  V-1.  Generic  Architecture  Diagram  Showing  WAN  Nod 


Figure  V-2.  Building  Blocks  for  Network  Architecture 


NTBN  ARCHITECTURE 


Figure  V-4.  Existing  AIS  Components  At  NTBN  Nodes 


NTBN  WAN 


Figure  V-4.  Existing  NTBN  Wide  Area  Network 


3.  WAN  Components 


A  Wide  Area  Network  includes  the  cable  plant,  interface  electronics  and 
associated  software  required  to  provide  network  services  to  users  distributed  over  a  wide  area  and 
connected  by  long-haul  communications  circuits.  For  the  existing  NTBN,  the  intelligent  switches 
(NX4600s),  link  enciyption  devices  (KG-94s),  and  T1  communications  circuits  shown  in  Figure 
V-4  are  WAN  components.  The  only  security  feature  associated  with  existing  NTBN  WAN 
components  is  the  Type  1  encryption  provided  by  the  KG-94s  on  the  dedicated  point-to-point 
communications  circuits  between  nodes.  These  WAN  components  do  not  provide  any  security 
features  which  would  peimit  the  WAN  to  operate  above  the  di^cated  mode. 

4.  AIS  Integration  Components 

AIS  Integration  Components  include  devices  such  as  gateways,  guards, 
bridges,  and  routers  which  allow  users  on  one  LAN  to  access  resources  on  another  LAN  or  on 
different  segments  of  the  same  LAN.  These  components  appear  at  the  boundaries  between  the 
LANs,  WANs  and  hosts  identified  in  Figure  V-2.  They  provide  the  "glue"  which  binds  separate 
AISs  into  an  integrated  network.  The  following  AIS  Integration  Components  have  potential 
application  to  the  NTBN  architecture: 

(1)  Guard.  A  processor  which  provides  a  filter  between  two  disparate  systems 
operating  at  different  security  levels  or  between  a  user  terminal  and  a  database  to 
filter  out  data  that  the  user  is  not  authorized  to  access. 

(2)  Bridge.  A  device  which  interconnects  LANs  and  which  may  restrict  packets  to  a 
local  segment  of  a  larger  network  for  performance  reasons.  As  shown  in  Figure  V- 
3,  bridges  are  used  at  the  NTF  to  connect  the  primary  node  LAN  to  other  LAN 
segments  on  which  NTF  hosts  are  installed. 

(3)  Router  or  gateway.  A  device  which  selects  the  optimial  route  to  send  traffic  over  a 
network  and  may  restrict  traffic  to  or  from  a  LAN  for  performance  reasons.  Unlike 
bridges,  routers  work  in  conjunction  with  specified  network  protocols  such  as 
Internet  Protocol  (IP).  As  shown  in  Figure  V-3,  routers  are  used  at  various  nodes 
to  extend  the  local  Ethernet  to  a  remote  location.  The  functions  of  a  bridge  and 
router  are  often  combined  in  a  single  product 

The  AIS  integration  components  currently  in  use  on  the  NTBN  have  not 
been  evaluated  for  compliance  with  NCSC  computer  security  guidelines.  Therefore,  the  network 
has  not  been  accredited  to  operate  beyond  tiie  dei^cated  mode. 

B.  Overview  of  Secure  Networking  Product  Technologies 

As  described  above,  products  with  potential  applications  to  NTBN  communications 
and  security  upgrades  may  be  grouped  into  four  categories-Host  Computers,  LAN  Components, 
WAN  Components,  and  AIS  Integration  Components.  The  choice  of  products  witlun  each 
category  is  driven  by  performance  and  security  ^uirements.  For  networlu  such  as  the  existing 
NTBN  operating  in  the  Dedicated  noode,  no  minimum  level  of  trust  is  required  by  the  governing 
DoD  standards  ^CSC  Rainbow  Series  publications),  and  products  may  be  selected  without  regard 
to  their  NCSC  certification  level.  NCSC  guidelines  reconunend  pit^ucts  with  a  Trusted 
Computing  Base  (TC3)  evaluated  at  the  C2  level  for  System  High  applications,  at  the  B 1  level  for 
Compartmented  mode  applications,  and  at  the  A  or  B2  level  for  Multilevel  mode  applications. 
Type  1  encryption  is  a  requirement  for  all  netwo^  which  transmit  classified  data  over  unprotected 
distribution  systems. 
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Table  V-1  is  a  summary  of  the  products  surveyed  during  the  preparation  of  this 
report  It  includes  products  which  are  currently  available  as  well  as  products  no  indcr 
development  The  columns  in  Table  V-1  are  the  four  product  categories  defi  d  in  paragraph  A 
above.  The  rows  are  based  on  a  further  categorization  of  products  as  defined  below: 

( 1 )  Evaluated  Products  list  (EPL)  Products.  Hardware/software  products  listed  on  the 
NCSC's  Evaluated  Products  List  (EPL)  in  one  of  four  phases  of  evaluation 
(Vendor  Assistance  Phase,  Design  Analysis  Phase,  Formal  Evaluation  Phase,  and 
Completed  Evaluations).  The  EPL  groups  products  functionally  into  four  types-- 
Unix-like  Systems,  Proprietary  Systems,  Networks  and  Network  Components, 
and  Subsystems.  The  Unix-like  and  Proprietary  Systems  are  computer  platforms 
with  secure  operating  systems  which  are  evaluated  with  respect  to  the  NCSC 
Trusted  Computer  System  Evaluation  Criteria  (Orange  Book).  They  appear  in 
Table  V-1  under  the  Host  Computer  column.  It  should  be  noted  that  some  of  these 
systems  have  been  configured  in  network  applications  as  gateways  and  guards,  and 
therefore  they  also  appear  under  the  AIS  Integration  Con^nent  column  of  Table  V- 
1,  The  EPL  Network  and  Network  Components  products  are  evaluated  in 
accordance  with  the  Trusted  Network  Inte^rctation  of  the  Trusted  Computer 
System  Evaluation  Criteria  (Red  Book).  EPL  Subsystem  ftoducts  are  those  which 
have  been  evaluated  with  respect  to  Orange  Book  criteria,  but  do  not  meet  full 
system  requirements  for  A,  B  or  C-level  ev^uation. 

(2)  Computer  Security  (COMPUSEC)  Products  Not  on  EPL.  Hardware/software 
products  which  have  been  designed  to  meet  NCSC  standards  or  which  include 
some  computer  security  features,  but  which  do  not  currently  appear  on  the  EPL 
under  any  of  the  four  evaluation  stages.  Examples  are  the  BLACKER  network 
components  developed  by  NSA  for  X.25  WAN  applications  and  the  TimeLAN  100 
FDDI  LAN  develop^  by  Unisys. 

(3)  Communications  Security  (COMSEC)  Products.  Devices  which  provide  Type  1 
encryption  at  the  Host,  LAN  or  WAN  level.  Two  products  listed  in  Table  V-1, 
BLACI^R  and  CANEWA^,  incorporate  both  COMSEC  and  COMPUSEC. 

(4)  Other  Products.  Commercial  products  which  provide  neither  computer  security 
nor  Type  1  encryption  capabilities.  They  are  listed  in  Table  V-1  because  there  are 
many  applications  in  a  secure  network  for  products  which  incorporate  neither 
COMSEC  nor  COMPUSEC  features.  One  exan^le  is  a  single-level  hosts  or  LAN 
which  is  connected  to  an  MLS  networic  by  an  AIS  Integration  Component  with  an 
appropriate  TCB.  Another  cxan^le  is  a  WAN  communications  component  such  as 
a  packet  switch  located  on  the  BLACK  side  of  tiie  WAN  COMSEC  device. 

The  Tiger  Team  drew  two  important  conclusions  from  its  survey  of  available 
networking  products.  First,  members  agreed  that  products  arc  available  today  to  integrate 
generation  MLS  capability  for  the  NTON.  Second,  the  Tiger  Team  concluded  that  an  MLS 
network  meeting  NTBN  requirements  cannot  now  be  assembled  from  the  small  set  of  products 
which  have  successfully  completed  NCSC  evaluation.  Products  from  <^h  of  the  four  categones 
defined  above  must  be  considered  for  the  near-term  MLS  implementation.  The  Tiger  Tern  also 
concluded  that  it  may  be  necessary  to  work  witii  vendors  to  define  enhancements  which  will  bring 
existing  products  into  compliance  with  NTBN  requirements.  The  Architecture  discussions  in  the 
following  sections  provide  guidance  on  integrating  the  secure  networking  products  ^d 
technologies  introduced  in  tiiis  section  into  the  NTBN  to  achieve  a  multilevel  secure  nework.  The 
guiding  criteria  in  selecting  products  will  be  interoperability  requirements  (i.e.,  compliance  with 
DoD  protocol  standards)  and  performance  requirements  (i.e.,  data  transfer  speeds  consistent  with 
those  on  the  existing  network). 
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TABLE  V-1 

SUMMARY  OF  APPLICABLE  PRODUCTS 


DESCRIPTION 


OF 

PRODUCTS 

HOST 

COMPUTERS 

LAN 

COMPONENTS 

EPL 

PRODUCTS 

UNIX-like  Systems 
(16  EPL  Produas) 

Verdix  VSLAN 
(Completed 

Evaluation  at  B2 
Level) 

Proprietary 

Systems 

(23  EPL  Produas) 

Boeing  MLS  LAN 
(Formal  Evaluation 
Phase  for  Al  Level) 

Evaiuateo 

Subsystems 

Meeting  Seleaed 
COMPUSEC  romts. 

Gemini  NetworK 
Processor  (Design 
Analysis  Phase  for 

A1  Level) 

PRODUCT  CATEGORIES 


WAN 

COMPONENTS 


COMPUSEC 
PRODUCTS 
NOT  ON  EPL 


Unisys  limeLan  100  I  BLACKER  From  End 


FDDILAN 


COMSEC 
PRODUCTS 
(TYPE  1) 


OECDESNIC  CANEWARE 

Secure  Ethernet  LAN  (Designed  to  B2 
Standards) 


Motorola  NES 
Products 


(Designed  to  A1 
Stanoards) 


AIS  INTEGRATION 
COMPONENTS 


Loral  MLS'100 
Gateway 

(Vendor  Assistance 
Phase-B2) 


UNIX'like  and 
Proprietary  Syst. 
Configured  as 
Guards/Gateways 
(Examples  are  the 
HFSI  XTS-200  and 
the  Gemini  GEMSOS 
Guard) 


Verdix  Secure 
IP  Router  (EPL 
Application  Pending) 


DEC  One  Way 
Gateway 


OTHER 

PRODUCTS 

(NOT  COMPUSEC 
OR  COMSEC} 


Commercial  Host 
Platforms 


Commercial  LANs 


Xerox  XEU 
(Link  Encryption 
Device) 


Wang  TIU 

(Link  Encryption 

Device) 


BLACKER  From  End 
(X.25  Network 
Encrvotion  Device) 


CANEWARE 
(SDNS  Encryption 
Device) 


STU-III  and  KG- 
Link  Encryption 
Devices 


Packet  Commercial 

Switching  Products  Protocol  Converters 


Intelligent  Data  PBXs  Commercial  Router 
Gateway  and 
Produas 


Commercial  Bridge 
Produas 
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VI.  SYSTEM  DESCRIP^  IN 


The  NTBN  security  and  communications  architecture  system  description  contains 
two  essential  areas: 

( 1 )  An  NTBN  operational  concept,  and 

(2)  NTBN  security  architecture. 

The  operational  concept  details  the  communications  and  security  management  considerations  for 
the  NTBN.  The  architecture  section  provides  a  description  of  alternative  approaches  to  providing  a 
secure  and  responsive  NTBN,  and  proposes  a  recommended  NTBN  communications  and  security 
architecture. 


A.  Operational  Concent 

The  communications  and  security  policy  for  the  NTBN  shall  be  considered 
throughout  the  life  cycle  of  the  Automated  Information  System  (AISs)  Md  the  network  from 
beginning  of  concept,  through  design,  development,  operation,  and  maintenance.  The  cycle 
should  ensure  early  and  continuous  involvement  of  the  users,  information  system  security  officers, 
data  owners,  and  Designated  Approving  Authority  (DAA)  in  defining  and  implementing  the 
security  requirements  of  the  AISs.  The  DAA  is  the  person  designated  as  responsible  for  the  overall 
security  of  AISs  and  networks  for  a  major  command  or  agency.  This  operational  concept  for  the 
NTBN  security  and  communications  architecture  covers  organizational  management,  network 
security  management,  configuration  management,  cryptographic  management,  risk  management, 
and  operation^  test  and  evaluation. 


1.  Organizational  Management 


The  NTBN  crosses  a  myriad  of  DAA  boundaries  when  network 
connections  are  provided  to  various  Government  agencies  and  contractors.  Although  the  Strategic 
Defense  Initiative  Organization  (SDIO)  has  authority  over  the  NTBN,  there  are  several  other 
command  and  agency  DAA’s  that  have  control  over  their  respective  AISs.  Currently  the  list  of 
DAA's  includes  United  States  Army  Strategic  Defense  Command  (USASDC),  Department  of  the 
Energy  (DOE),  US  Space  Command  (USSPACCOM),  Naval  Research  Laboratory  (NHL), 
Strategic  Air  Command  (SAC),  Defense  Investigative  Service  (DIS)  and  Space  Systems  Division 
(SSD).  The  SDIO  shall  develop  agreements  with  these  organizations  and  any  future  organizations 
at  the  policy  level  and  the  operatitmal  level  relative  to  security  of  the  NTBN  and  respective  AISs. 


a. 


dm: 


iiim  of  Agreement  (MOA) 


The  NTBN  is  a  network  of  AISs  previously  accredited  by  their 
respective  command  DAA.  DoD  Directive  (DoDD)  5200.28  states  that  if  the  network  consists  of 
previously  accredited  AISs,  an  MOA  is  required  between  the  DAA  of  each  DoD  Component  AIS 
and  the  DAA  responsible  for  the  network,  SDIO.  The  memorandum  of  a^ment  betwwn  DAAs 
must  recognize  each  DAA's  scope  of  responsibilities,  encompass  the  security  glides  Md  practices 
of  each  DAA,  and  other  information  included  in  DoDD  5200^8  Para^ph  D.  The  MOA  shodd 
reconcile  different  security  policies  and  philost^hies  of  protecticMi  and  identify  the  cOTdinons  uiider 
which  specified  classes  of  information  can  be  exchanged.  The  security  of  each  MS  cormected  to 
die  network  remains  the  responsibility  of  its  individual  DAA.  The  DAA  resptxisible  fw  the  ovei^ 
security  of  the  network,  SDIO,  shall  determine  the  security  and  protection  rcquiren^ts  for 
connection  of  AISs  to  the  network  and  have  the  authority  and  responsibility  »  rem^e  irom  *e 
network  any  AIS  not  adhering  to  the  security  requirements  of  the  network.  Each  MOA  shodd 
outline  how  the  DAAs  deal  with  security  issues  and  how  to  resolve  any  differences.  The  foUowing 
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is  a  list  of  recommendations  for  the  contents  of  the  MOA  and  supporting  documents  taken  from  the 
Trusted  Network  Interpretation  guideline: 

(1)  A  general  description  of  the  information  that  will  be  transmitted  to  the  network  by 
each  AIS. 

(2)  A  summary  discussion  of  the  trusted  behavior  that  is  expected  from  each  AIS. 

(3)  The  details  of  the  overall  security  plan  for  the  network  and  the  assignment  of 
responsibility  for  producing  and  accepting  the  plan. 

(4)  A  description  of  the  overall  network  security  policy. 


(5)  Specification  of  the  security  parameters  that  are  to  be  transmitted  between 
communicating  AISs 

(6)  A  discussion  of  security  details  that  are  relevant  to  the  exchange  of  information 
among  the  AISs. 

(7)  A  description  of  the  user  community,  including  the  lowest  clearance  of  any  user 
who  will  have  access  to  the  network. 

(8)  Any  special  considerations  for  connections  to  any  AIS  in  the  network,  including 
potent  security  threats  and  the  safeguards  that  will  be  used. 

(9)  A  description  of  the  security  protection  features  provided  by  the  data 
communications  and  network  security  control  devices. 

(10)  A  description  of  the  information  that  each  AIS  will  log  in  the  audit  trail  and  how 
auditing  tasks  will  be  divided  among  AISs. 

(1 1)  A  description  of  the  information  security  services  to  be  offered  to  the  network  by 
each  AIS. 

b.  Intersite  MOA 

The  operational  computer  sites  that  are  nodes  of  NTBN  and  the 
NTBN  manager  should  establish  MOAs  to  cover  the  various  operational  security  aspects  of  the 
DAA  MOAs.  These  MOAs  should  establish  how  controlling  mechanisms  are  employed  and 
establish  reporting  procedures  for  security  requirements,  modifications  and  incidents. 

2.  Network  Security  Management 

a.  Access  Control 

The  network  access  control  mechanisms  must  enforce  the  network 
security  policy.  The  network  must  control  access  to  network  resotrces  ^ed  on  classification 
level  (MAC  [mandatory  access  control])  and  need-to-know  (DAC  [discretionary  access  control]). 
In  this  way,  data  transmission  and  reception  across  the  network  will  be  mediate  by  the  network 
and  only  those  resources  with  the  correct  clearance  and/or  need-to*know  will  be  able  to 
communicate.  The  network  must  be  able  to  authenticate  the  identity  of  its  attached  computers  to 
ensure  correct  knowledge  of  classification  levels. 
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Network  access  control  can  be  accomplished  by  the  use  of  separate 
networks  for  each  classification  level  processed  or  by  use  of  multilevel  secure  (MLS)  network 
devices. 


b.  Audit 

The  audit  mechanism  of  a  network  has  five  important  goals.  First, 
the  audit  must  allow  the  review  of  patterns  of  access  to  individual  systems.  Second,  the  audit 
mechanism  must  allow  the  discovery  of  both  user  and  outsider  attempts  to  bj^^s  protection 
mechanisms.  Third,  the  audit  mechanism  must  allow  discovery  of  any  use  of  privilege  that  may 
occur  on  the  network.  Fourth,  the  audit  mechanism  must  act  as  a  deterrent  against  perpetrators 
habitual  attempts  to  bypass  the  system  protection.  Finally,  the  au^t  mechanism  must  supply 
assurance  that  attempts  to  bypass  the  network  security  mechanisms  will  be  recorded  and 
discovered. 

c.  Intrusion  Detection 

The  network  should  provide  a  means  to  automatically  discover  any 
attempts  to  bypass  network  security  controls  or  to  discover  any  actual  breach  of  network  security. 

Audit  mechanisms  collect  massive  anwunts  of  information  regarding 
the  security  operation  of  the  network.  An  intrusion  detection  system  is  needed  to  analyze  the  audit 
log(s)  to  allow  the  Network  Security  Officer  (NSO)  to  obtain  data  on  Ae  secure  operation  of  Ae 
network.  A  real-time  intrusion  detection  system  is  highly  desired.  Tlus  type  of  system  would  be 
able  to  analyze  netwcHk  auAt  logs,  m  real-time,  and  determine  if  security  anomalies  are  occurring. 
A  non-rcal-timc  system,  which  is  less  desirable,  would  perform  post-processing  of  audit  data  and 
would  still  be  mvaluable  to  Ae  NSO  who  would  not  have  to  examine  voluminous  auAt  logs  wiA 
Ae  high  potentiality  of  missing  security  anomalies. 

d.  Configuration  Management 

A  formal  network  configuration  control  board  (NCCB)  for  Ae 
NTBN  should  be  established.  This  NCCB  should  establish  procedures  for  changes  to  the 
network,  review  proposed  changes  and  pass  recommendations  to  the  DAA  where  network  security 
would  be  affected,  ^nfiguration  management  procedures  identify  the  configuration  of  a  ne^ork 
at  Ascrete  points  in  time  for  Ae  purpose  of  systematically  controlling  changes  and  maintaining 
integrity  and  traceability  of  this  configuration  throughout  Ae  network  life  cycle.  Configuration 
management  consists  of  identification,  control,  status  accounting  and  auAting. 

(1)  Identification  is  to  identify  Ae  components  of  Ae  network  design  and  Ae 
implementation. 

(2)  Control  mvolves  Ae  systematic  evaluation,  coordination,  approval/Asapproval  of 
proposed  changes  to  Ae  design. 

(3)  Stams  accounting  is  to  record  and  report  all  information  that  is  of  significance  to  Ae 
configuration  management  process. 

(4)  AuAt  is  checking  Ae  top  to  bottom  completeness  of  Ae  configuration  to  ascertain 
Aat  only  auAorized  changes  have  been  made  in  Ae  network  hardware,  software  or 
firmware. 
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e. 


Cryptographic  Management 


To  provide  data  confidentially  and  integrity,  as  well  as  network 
control  integrity,  NSA  Type  1  cryptographic  devices  must  be  used  on  all  network  communications 
circuits  that  are  not  security  controlled  (e.g.,  not  in  secure  spaces  or  protected  wire-line  distribution 
systems).  In  addition,  encryption  can  be  used  to  provide  data  privacy  and  separation  of 
classification  communities. 

f.  Risk  Management 

No  security  system  is  perfect.  The  risk  remaining  in  a  proposed 
AIS  must  be  assessed  and  if  found  to  be  acceptable  to  the  DAA,  granted  accreditation.  All  AISs 
must  be  accredited  before  they  may  process  or  use  classified  information,  unless  a  written  waiver 
is  granted  by  the  DAA.  The  ^creitation  of  an  AIS  is  based  upon  a  technical  investigation  and  a 
formal  review  in  accordance  with  DoD  5200.28.  The  DAA  must  ensure  that  satisfactory  security 
measures  have  been  installed  and  that  any  residual  risk  is  within  acceptable  limits  which  must  be 
weighed  against  operational  necessity. 

DoD  5200.28  (enclosure  4)  states  that  the  risk  assessment  method 
for  evaluating  AISs  will  be  the  procedure  bas^  upon  CSC-STD-(X)3-85,  the  "Yellow  Book."  Any 
DoD  component  desiring  to  use  a  different  method  to  accomplish  the  intent  of  the  5200.28  may  do 
so  only  with  prior  approval  granted  by  ASD  (C3I).  DoD  5200.28  does  not  define  accreditation 
requirements  for  non-DoD  AISs  or  for  connecting  non-DoD  AISs  to  DoD  systems.  An  alternative 
to  the  Yellow  Book  method  has  been  developed  by  the  Naval  Research  Laboratory.  The  Yellow 
Book  takes  the  high  level  view  of  the  system  risk  whereas  the  NRL  paper  includes  several  more 
detailed  aspects  of  the  system  processing.  The  NRL  methodology  encompasses  all  of  the  Yellow 
Book's  methodology,  but  because  of  its  finer  granularity,  may  be  more  applicable  for  use  in  the 
NTB  environment  Tlie  NRL  methodology  provides  a  more  in-depth  risk  analysis  and  could  result 
in  a  more  precise  set  of  requirements  based  on  the  environmental  usage  of  the  system.  This 
method  warrants  fuller  investigation  in  coordination  with  ASD  (OI). 

SDIO  Manual  5206  requires  an  armual  accreditation  review  for  each 
AIS.  An  accreditation  review  consists  of  an  inspection  of  an  AIS  or  network,  its  capabilities,  and 
its  physical  facilities  to  include  the  following  activities:  1)  reevaluation  of  the  need  for  accreditation 
at  the  current  sensitivity  level;  2)  evaluation  of  the  current  accreditation;  3)  determination  of 
problem  areas  or  unresolved  issues;  and  4)  determination  of  the  adequacy  of  the  implementation  of 
the  security  approach.  These  reviews  should  be  conducted  by  personnel  independent  of  the  AIS  or 
network  staff.  A  successful  accreditation  review  indicates  that  the  previous  accreditation  is  still 
valid.  Otherwise,  the  accreditation  process  defined  in  SDIO  Manual  52()6-M  must  be  initiated. 

After  initial  DAA  accreditation,  the  risk  management  is  a  recurring 
process  and  must  correlate  with  network  configuration  control.  Each  time  a  network  configuration 
change  is  proposed,  a  risk  assessment  must  accomplished  to  determine  potential  impacts  on 
current  acceptable  risks.  Network  changes  must  be  viewed  in  relation  to  the  current  existing 
network  to  ensure  no  new  risks  are  introduced.  SDIO  Manual  5206-M  defines  the  types  of 
changes  which  require  coordination  with  the  SDIO  DAA  prior  to  in^lementation  of  the  changes. 

g.  Operational  Test  and  Evaluation 

Network  security  mechanisms  must  work  correctly  because  they  ^ 
relied  upon  to  provide  network  protection  against  security  bypass  resulting  in  security 
compromise.  In  addition,  distributed  security  mechanisms  must  intooperate  with  one  another  to 
provide  network  security. 
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In  order  to  ensure  that  the  security  mechanisms  work  correctly, 
assurance  of  correct  operation  must  be  provided.  The  assurance  is  a  result  of  design  and 
implementation  evaluation  and/br  verification.  Evaluation  and  verificadon  can  be  done  in  a  formal, 
mathemarical  manner  (using  predicate  calculus  analysis),  by  exhaustive  operational  testing,  or 
both.  The  secure  interoperation  of  network  components  must  be  shown  to  work  correctly. 

There  must  be  continual  testing  of  security  enforcement  mechanisms 
throughout  the  operational  life-cycle  of  the  network  to  assure  continu^  secure  operations.  This 
testing  could  use  both  off-line  and  on-line  methods.  In  an  off-line  fashion,  network  components 
and  systems  could  be  removed  from  the  active,  operational  network  and  installed  on  an  off-line, 
non-operational  test  network.  Under  the  direction  of  the  network  security  manager  (NSM),  tests 
would  be  implemented  to  attempt  to  bypass  the  component's  network  security  features  and 
mechanisms.  To  prove  that  the  component  was  operating  securely,  not  only  should  the  bypass 
tests  fail,  but  the  fact  tiiat  the  tests  were  attempted  should  appear  in  the  network  audit  log  and 
should  be  exposed  as  possible  attempts  to  breach  security  by  the  intrusion  detection  system. 

These  same  types  of  tests  could  be  run  in  an  on-line  fashion,  but 
only  with  the  strict  advice,  consent,  and  supervision  of  all  of  the  cognizant  network  security 
authorities  responsible  for  the  network's  secure  operation.  Tests  performed  on  an  operationsd 
network  may  cause  undesirable  side-effects  such  as  disruption  of  network  services.  Therefore, 
users  should  be  warned  that  such  tests  are  to  be  undertaken,  or  the  testing  should  be  performed  at 
non-critical  or  off-peak  utilization  times  (i.e.,  midrught  to  8:00  a.m.). 

B.  Architecture 

1.  Introduction 

In  defining  a  responsive  NTBN  communications  and  security  architecture,  a 
comprehensive  examination  of  feasible  architectural  alternatives  was  conducted.  The  architectural 
alternatives  were  driven  by  the  compiled  functional  r^uirements.  The  global  set  of  alternatives 
may  be  categorized  within  two  areas:  (1)  multiple,  single  level  networks  (Figure  VI-1),  or  (2)  a 
single,  multilevel  secure  network  (Figure  VI-2).  Given  that  the  NTB  has  requirements  to  provide 
processing  and  data  storage  for  users  who  are  not  all  cleared  to  the  same  classification  level,  the 
NTBN  must  provide  assured  separation  of  user  data  on  the  network.  This  can  be  provided  for  by 
either  of  the  two  types  of  architectures.  The  overall  tradeoff  of  the  two  architectures  is  driven  by 
responsiveness  and  cost. 

The  NTB's  current  configuration  consists  of  several  independent  networks. 
Some  networks  are  unclassified;  the  others  operate  either  in  a  Dedicated  or  Systein  High  mode  with 
users  cleared  to  the  highest  level  of  data  processed  on  the  network.  The  requirements  analysis 
documented  in  Annex  1  of  this  repon  supports  the  need  for  several  more  single-level  networks  in 
order  to  serve  the  needs  of  the  NTB's  users. 
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Figure  VI-1.  Separate  Single  Level  Networks 


As  an  alternative  to  the  proliferation  of  multiple,  single  level  networks,  a 
single,  multilevel  secure  (MLS)  network  could  be  employed  to  support  Ae  NTB  users.  The  MLS 
nerwOTk  architecture  could  use  a  single  network  backbone  to  provide  services  to  users  with  varying 
security  clearance  levels  and  computers  with  data  of  varying  levels  of  classification. 

CONSOLIDATED  NETWORK 


Figure  VI-2.  Single  Multilevel  Networks 


A  priority  of  providing  additional  NTB  security  functionality  is  to  do  so 
with  the  provision  of  working  within  the  framework  of  network  standards,  whether  they  be 
domestic  (DoD,  GOSIP)  or  international  (ISO/OSI).  From  a  cost  standpoint,  as  well  as  an 
interoperability  standpoint,  a  heterogeneous  and  multivendor  network  is  most  desirable.  As  more 
standardized  secure  products  make  their  way  into  the  marketplace,  the  NTBN  can  incorporate  these 
equipments  to  upgrade  network  security.  This  will  allow  the  NTBN  to  reap  the  benefits  of  new 
technology  as  advancements  are  made  by  system  vendors.  For  these  reasons,  a  potential 
proprietary  solution  to  the  NTB  MLS  problem  was  not  favorably  accepted  by  the  Tiger  Team  due 
to  Ae  overriding  reliance  on  a  particular  vendor’s  technology  solution(s),  cquipmcnt(s),  and 
communications  protocols.  The  computer  and  network  world,  as  it  is  seen  today,  is  one  that  is 
quickly  migrating  to  open  systems  standards. 

2.  Strawman  Architectures 

As  stated  in  the  previous  section,  the  two  major  architectural  designs  that 
can  be  utilized  to  provide  overall  network  system  security  for  the  NTB  are  multiple,  single  level 
networks,  and  a  single,  MLS  network.  From  a  high  level  perspective,  these  networks  can  be 
considered  "back-bone"  networks  -  that  is,  networks  that  transport  data  from  source  to  destination 
without  regard  to  the  acmal  underlying  technology  that  provides  the  data  movement.  In  faa,  from 
the  user's  perspective,  it  does  not  matter  whether  the  underlying  back-bone  network  is  copper 
cable  or  fiber  optic,  or  whetiier  it  is  considered  a  local  area  network  (IJ^  or  a  wide  area  network 
(WAN).  The  distinction  between  LAN  and  WAN  has  become  blurred  in  recent  years  because  both 
technologies  are  being  used  in  complimentary  architectures,  or  in  architectures  that  had  once  been 
the  other's  exclusive  domain. 

Most,  if  not  all,  modem  networking  systems  employ  a  technology  known 
as  packetization  of  data.  This  means  that  the  data  traversing  the  network  is  grouped  into  packets 
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(or  frames)  of  a  finite  size  of  bits  (which  may  vary  among  network  system  implementations  and 
may  also  be  dynamic  within  a  network),  with  each  packet  having  an  individual  header  ^ically 
denoting  where  the  packet  came  from  and  where  it  is  going  to  (i.e.,  its  source  and  destination). 

As  a  result  of  the  basic  research  carried  out  in  the  late  1960s  which  resulted 
in  the  ARPANET,  packetized  data  was  routed  fiom  its  source  to  its  destination  via  a  technology 
known  as  "packet  switching."  Packet  switching  implies  that  there  are  store  and  forward  packet 
switching  nodes  which  make  routing  decisions  bas^  on  a  knowledge  of  the  network  topology. 
The  packet  switching  nodes  forward  the  packets  to  a  neighboring  switching  node  in  order  to 
deliver  the  packet  to  its  final  destination.  Until  the  advent  of  the  ubiquitous  local  area  network 
(such  as  Ethemet/IEEE  802.3),  basically  all  packet  network  systems  were  packet  switching 
systems. 


Network  systems  which  employ  a  bus  (i.e.,  IEEE  802.3/Ethemet)  or  ring 
technology  (i.e.,  TREE  802.5/IBM  Token  Ring)  differ  from  those  that  employ  packet  switches  in 
that  the  bus  or  ring  systems  do  not  switch  or  route  packets.  The  packets  are  broadcast  on  the 
transmission  medium  with  source  and  destination  addresses.  All  systems  attached  to  the  network 
read  all  the  packets  "flying"  across  the  network.  The  attached  system  reads  the  packet  header  to 
determine  if  the  packet  is  designated  for  itself.  If  it  is,  the  packet  is  passed  up  to  its  intended 
application.  If  it  is  destined  for  another  system,  the  packet  is  discarded. 

There  are  many  network  security  problems  that  network  implementors  are 
faced  with.  In  the  forefront,  is  the  issue  of  data  confidentiality.  In  a  network  environment,  <kta  is 
passed  between  computer  systems  via  a  physical  medium.  Most  of  those  physical  media  are 
tappable  or  interceptable.  This  means  that  all  the  data  that  flows  across  the  "wires"  (whether  they 
really  be  copper  wires,  fiber,  or  RF)  is  in  danger  of  being  read  or  modified  in  transit.  The 
modification  of  data  brings  up  the  issue  of  data  integrity.  The  recipient  of  the  data  needs  to  know 
how  reliable  the  data  is  -  for  example,  is  the  data  that  was  received  the  data  that  was  actually  sent 
and  was  it  sent  by  whom  it  says  it  was  sent  by.  The.  question  of  authenticity  of  the  source  of  the 
data  implies  that  there  is  the  piDssibility  that  someone  other  than  the  legitimate  data  source  could 
masquerade  as  that  legitimate  source  and  possibly  spoof  the  data  recipient  into  performing  actions 
that  were  unwarranted. 

Interconnection  of  network  components  also  presents  a  problem  when  those 
components  are  operating  on  data  that  needs  to  be  protected  differently.  For  example,  one  host 
may  process  and  store  data  at  the  secret  level,  while  another  host  might  process  and  store  data  at 
the  unclassified  level.  If  there  were  uncleared  users  on  the  unclassified  machine,  tiie  two  systems 
could  not  be  connected  because  there  would  be  the  possibility  that  uncleared  users  could  obtain 
classified  data.  Only  if  the  hosts  or  a  network  interface  supported  multilevel  operations,  could 
these  two  systems  be  connected  with  uncleared  users.  In  many  instances,  the  resultant  segregation 
of  systems  causes  a  loss  of  system  functionality  because  there  may  be  a  mission  requirement  to 
move  data  from  an  unclassified  system  to  a  classified  system.  Currently,  security  policies  would 
prohibit  such  a  connection  unless  appropriate  (i.e.,  trusted)  safeguards  were  employed. 

a.  Multiple  Single  Level  Networks 

In  order  to  support  users  who  are  not  cleared  to  the  highest  clearance 
level  of  data  being  processed  or  stored  on  NTB  computing  equipment,  the  NTB  network 
architecture  must  enforce  user  separation  so  th^  those  users  will  not  be  able  to  access  data  or 
processors  at  classification  levels  Mgher  than  tiieir  clearance  level.  One  method  of  providing  this 
separation  is  to  provide  each  clearance  level  of  users  with  their  own  set  of  network  resources  - 
separate  network  cable  plant,  network  operations  and  control,  and  computing  facilities  to  process 
and  store  data. 
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It  has  been  shown  by  the  user  requirements  database  (ref.  Annex  A  - 
Requirements  Database)  that  there  is  a  need  for  NTB  processing  at  the  following  levels: 
Unclassified,  Secret,  Secret  with  compartments.  Secret  with  company  proprietary.  Secret  without 
any  NOFORN  data,  and  Top  Secret.  This  would  require  the  use  of  at  least  six  separate  sets  of 
computing  and  communications  resources  within  the  framework  of  the  NTB. 

It  is  not  clear  that  all  the  replicated  levels  would  require  a  total 
duplication  of  hardware  resources,  but  it  could  be  expected  Aat  at  least  several  of  the  levels  would 
require  major  supercomputer  or  mainframe  investments  (e.g..  Secret,  Secret  with  compartments. 
Secret  with  company  proprietary.  Secret  without  NOFORN,  and  Top  Secret  all  might  require 
continual  usage  of  a  CRAY  supercomputer  for  simulations  along  with  communications  networking 
components).  If  CRAY  supercomputers  were  required  on  all  of  the  networks,  despite  the  fact  that 
there  was  excess  capacity  on  each  of  the  CRAYs,  the  cost  would  be  astronomical  (e.g.,  six 
systems  at  approximately  $15  million  per  system,  resulting  in  a  $90  million  dollar  investment), 
llie  excess  capacity  of  each  of  the  machines  could  not  be  used  by  another  classification 
environment  bemuse  of  the  potential  for  security  compromise.  Each  separate  network  would  also 
require  additional  computational  systems  such  as  file  servers,  workstations,  terminals,  printers, 
and  network  hardware  (routers,  bridges,  taps,  cable,  etc.) 

Overall,  the  multiple,  single  level  networks  are  simpler  to 
understand  and  their  security  mechanisms  are  much  less  complex  than  the  single,  MLS  network. 
They  are  secure  and  fully  meet  the  NTB's  need  for  separation  of  users  and  data  based  on  clearance 
and  classification.  On  the  other  hand,  there  is  a  veiy  high  cost  in  replicating  the  hardware, 
software,  administrative  personnel,  operations  personnel,  and  support  personnel  for  each  security 
level  environment 

b.  Single.  Multilevel  Secure  Network 

Instead  of  multiple,  single  level  networks,  the  NTB  could  employ  a 
single,  multilevel  secure  network.  Such  a  network  could  be  built  using  several  commercial 
products  that  have  either  been  or  are  being  evaluated  by  the  National  Computer  Security  Center 
(NCSC)  for  use  in  multilevel  secure  environments. 

Using  such  MLS  products,  single  level  or  multilevel  computing 
resources  (e.g.,  supercomputers,  mainframes,  workstations,  PCs,  terminals)  could  be  connected 
to  MLS  network  interface  devices.  These  inte^ace  devices  would  be  initiated  and  controlled  by  a 
Network  System  Security  Officer  from  a  Network  Security  Controller  console  station.  The  MLS 
network  interface  device  would  be  instructed  by  the  NSO  whether  to  treat  an  attached  computer  as 
single  or  multilevel.  If  the  computer  were  to  be  treated  as  a  single  level  resource,  the  specific 
classification  level  would  be  indicated  (c.g..  Secret,  Top  Secret).  The  MLS  networic  interface 
devices  would  then  be  responsible  for  attaching  the  correct  security  label  to  all  data  transmitted 
from  the  attached  computer.  It  would  also  be  responsible  for  ensuring  that  any  data  received  from 
the  network  is  labeled  exactly  the  same  as  the  indicated  classifreation  level  of  the  attached 
computer.  Otherwise,  the  received  data  will  not  be  forwarded  to  the  computer  and  this  event 
should  be  audited. 


ff  a  multilevel  device  is  defined  by  the  NSO,  tfien  the  MLS  network 
interface  device  would  be  defined  to  transmit  and  receive  data  within  a  specific  range  of 
classification  levels.  For  example,  a  multilevel  secure  computer  might  be  allowed  to  process  data 
in  the  range  of  Secret  to  Top  Secret  Therefore,  any  data  diat  does  not  fall  within  &at  range  wodd 
not  be  passed  through  the  MLS  network  interface  device.  The  MLS  network  interface  device 
would  be  responsible  for  checking  the  level  of  the  data  as  labeled  by  the  MLS  computer  to  ensure 
that  the  data  is  correctly  labeled  within  the  specified  range.  Any  violations  of  securi^  classifreation 
would  be  audited  by  Ae  MLS  network  interface  device.  These  audit  notification  would  then  be 
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examined  by  the  network  system  security  officer  and/or  an  audit  intrusion  detection  system  to 
provide  security  alerts. 


The  MLS  network  interface  devices  could  be  designed  for  use  on 
local  area  networks  (e.g.,  Ethernet,  Token  Ring,  FDDI),  or  could  be  designed  for  wide  area 
networks  (e.g.,  X.25,  DDN,  frame  relay,  ISDN,  MAN).  The  naajor  difference  would  be  in  the 
network  access  speed  that  would  be  required  by  the  network  interface  device.  Segments  of  the 
overall  network  would  be  interconnected  using  secure  routers/gateways,  bridges,  and 
communications  security  (CXDMSEC)  devices. 

The  major  costs  that  would  be  incurred  would  be  the  procurement  of 
the  MLS  network  interface  device  components  and  the  MLS  network  security  controller.  One 
MLS  network  interface  device  might  have  to  be  purchased  for  c^h  computing  resource  attached  to 
the  MLS  network  backbone  which  could  be  relatively  expensive.  On  the  other  hand,  computers 
could  be  clustered  into  communities  of  interest  or  separate  single-level  systems,  and  each  of  these 
clusters  could  then  be  gatewayed  onto  the  MLS  network  throu^  an  MLS  network  interface  device. 
This  might  be  cheaper,  ^m  an  initial  hardware  investment  standpoint,  but  with  greater  usage  of 
MLS  network  components  (or  through  large  quantity  discount  purchases),  the  prices  of  MLS 
network  interface  devices  can  be  expected  to  drop  dramatically  over  the  next  few  years. 

Single  level  computer  systems  might  still  have  to  be  housed  in 
separate  facilities  until  such  time  that  they  are  able  to  be  ^  in  multilevel  secure  mode.  But, 
network  operations  personnel  would  not  have  to  be  replicated.  There  would  be  a  need  for 
additional  security  personnel  to  ensure  correct  network  operations,  but  the  numbers  involved 
would  not  be  as  great  as  the  numbers  necessary  for  the  many  replicated  networics. 

c.  (Comparative  Analysis 

Following  a  thorough  review  of  the  technology  options  available  for 
meeting  NTBN  communications  and  security  requirements,  the  Tiger  Team  concluded  that 
establishment  of  MLS  networks  is  now  a  realistic  alternative  to  the  continued  proliferation  of  the 
single-level  networks.  The  decision  to  recommend  an  MLS  NTBN  architecture  was  driven  by 
several  key  factors.  First,  it  will  be  prohibitively  expensive  over  the  long  term  to  duplicate 
communications  and  processing  systems  for  NTBN  users  at  all  the  classification  levels  for  which 
test  bed  services  will  be  required.  Second,  single-level  networks  cannot  efficiently  support  the 
future  operational  needs  of  the  diverse  SDI  user  community.  Finally,  the  components  of  a  first- 
generation  MLS  network  are  now  commercially  available  as  a  result  of  recent  industry  and 
Government-sponsored  product  development  and  certification  efforts. 

Appendix  A  of  this  report  summarizes  the  Tiger  Team's  evaluation 
of  the  following  tiiree  alternative  architectures  for  a  multilevel  secure  NTBN: 

(1)  Architecture  1.  This  approach  uses  secure  routers  to  connect  MLS  LANs  to  a 
communications  network  secured  by  link  encryption  devices.  The  MLS  LANs  use 
commercially  available  networic  interface  units  and  control  processors  to  meet 
requirements  of  the  Trusted  Network  Interpretation  of  the  Trusted  Computer 
System  Evaluation  Criteria  published  by  the  National  Computer  Security  Center 
(NCSQ. 

(2)  Architecture  2.  This  approach  employs  the  Government-developed  BLACKER 
Front  End  (BFE)  or  CANEWARE  Front  End  (CFE)  devices  as  the  interface 
between  single-level  LANs  (or  hosts)  and  a  packet  switched  network.  BFE  and 
CFE  systems  provide  T^pe  1  encryption  as  well  as  computer  security  feamres 
meeting  Ae  NCSC  criteria  for  trusted  networks. 
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(3)  Architecture  3.  This  approach  combines  the  security  and  communicadons  features 
of  Architecture  1  and  Architecture  2.  BFE/CFE  devices  provide  a  packet  switched 
network  interface  for  MLS  LANs  as  well  as  single-level  LANs,  and  routers  provide 
a  point-to-point  interfaces  between  MLS  LANs. 

Candidate  architectures  were  evaluated  on  the  basis  of  their  security  features, 
performance,  compliance  with  networking  standards,  and  cost.  A  summary  of  this  evaluation  is 
provided  in  Figure  VI-3.  Specific  technical  evaluation  criteria  included  the  level  of  NCSC  . 
evaluation  achieved  by  products  used  in  the  architecture,  the  communications  throughput 
capability,  and  the  level  of  compliance  with  DoD  standard  protocols.  The  Tiger  Team  rul^  out 
architectures  based  on  proprietary  products  or  protocols  in  favor  of  a  tnulti-vendor  network 
environment  based  on  DoD  implementation  of  open  system  standards.  With  this  approach,  the 
NTBN  will  benefit  from  the  wide  range  of  new  security  and  communications  technologies  which 
will  emerge  as  both  industry  and  Government  continue  their  migration  toward  open  system 
standards. 


The  recommended  MLS  approach  for  the  NTBN  is  Architecture  1.  It  can  be 
implemented  at  selected  NTBN  nodes  on  a  prototype  basis  without  requiring  changes  to  the 
existing  NTBN  communications  architectiire  based  on  multiple  T1  circuits  between  nodes. 
Selection  of  Architecture  2  for  near-term  in^lementation  would  limt  inter-node  communications  to 
64  Kpbs,  the  throughput  of  a  Bre  device.  Selection  of  Architecture  1  for  a  prototype  system  does 
not  preclude  eventual  migration  to  an  Architecture  3  packet  switched  MLS  environment 
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•  Encryption 
•NCSC 

Evaluations 

•  MLS  implemented  at 
LAN  device  level 

•  Encryption  provided 
by  KGls  on  comm.  net. 

•  A1  and  B2  LANs  have 
completed  evaluations 

•  MLS  implemented  at 
WAN  node  level 

•  Encryption  provided  by 
BFE/CFE 

•  BLACKER  meets  A1 

•  CANEWARE  meets  B2 

•  MLS  implemented  at 

LAN  device  and/or 

WAN  node  level 

•  Combines  security 
features  of 

Architectures  1  &  2 

•  B2  LAN  based  on 
Ethernet/TCP/IP;  A1  on 
proprietary  protocol 

•  Uses  high  speed  (e.g.Tl) 
point-to-point  comm. 

•  BFE/CFE  comply  with 
X.25,  TCP/IP  protocols 

•  BFE  limited  to  64  Kbps 

•  CFE  (when  available) 
will  support  T1 

•  Combines 
communications 
features  of 

Architectures  1  &  2 

•  Compliance  with 

Standards 

•  Throughput 

Availability  of 

•  MLS  LANS  now  avail¬ 
able  from  Verdix  (B2), 
Boeing  (Al)&  Unisys 

•  BLACKER  is  currently 
available;  CANEWARE 
available  in  1  to  2  years 

•  Combines  availability 
features  of 

Architectures  1  &  2 

illlllllllllilllM 

•  Approximately  $1M 
for  interconnection  of 
200  workstations  at 
multiple  sites 

•  Approximately  $1.6M 
for  100  BFEs  and  20 
packet  switches  at 
multiple  sites 

•  Highly  dependent  on 
how  Architecture  1  &  2 
features  are  combined 

(excluding  labor 
for  engineering 
and  installation) 

Figure  VI-3.  Comparison  of  Alternative  MLS  Architectures 
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Examples  of  these  alternative  architectures,  using  currently  available 
network  security  con^nents,  are  provided  in  Appendix  A. 

3.  Selected  Architecture  Specification 

a.  Overview 


An  MLS  network  will  provide  user  support  on  the  NTB  at  costs 
which  are  much  lower  than  those  incurred  using  multiple,  single  level  networks. 


MLS  networks  provide  a  means  to  share  a  physical  transmission 
medium  among  several  classification  levels.  The  MLS  network  performs  a  separation  of  different 
classification  levels  so  that  access  control  is  enforced  based  on  user  clearance  and  data 
classification.  It  is  imperative  that  the  MLS  network  operate  correctly  such  that  separation  of 
classes  is  always  maintained.  Assurance  of  operational  correctness  is  required  to  mitigate  the  risk 
of  security  con^romise. 


The  MLS  network  architecture  is  best  specified  in  three  functional 
areas.  The  local  area  network  (LAN),  internet,  and  wide  area  network  (WAN)  backbone 
components  will  be  specified  in  the  following  sections,  and  are  illustrated  in  summary  format  in 
Figure  VI-4. 


•LAN  DEVICE  BASED 
APPROACH  MAINTAINS 
HIGH  SPEED  WITHIN 
TO  A  NODE 

•ROUTER/GATEWAY 
WITH  TYPE  1 
ENCRYPTION 
MAINTAINS  HIGH 
SPEED  BETWEEN 
NODES 

•CURRENT  VENDOR 
PRODUCTS  PROVIDE 
A  LESSER  THAN  IDEAL 
LEVEL  OF  SECURITY, 
HOWEVER,  PROGRESS 
SHOULD  BE  FORTH¬ 
COMING 


Figure  VI-4.  MLS-LAN  Orientation  for  Architecture  1 
b.  Local  Area  Network 

The  local  area  network  (LAN)  component  shall  provide  assu^ 
mandatory  and  discretionary  access  control  mechanisms  to  provide  separation  of  classification 
levels  and  need-to-know.  The  LAN  shall  be  DoD  standard  protocol  suite  compUant  -  TCP/IP 
currently,  GOSIP  in  the  future.  It  shall  securely  interoperate  with  the  Internet  and  WAN  Backbone 
Layers. 
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The  LAN  layer  will  be  able  to  suppon  both  single  level  and 
multilevel  attached  computers.  Single  level  computers  shall  be  treated  at  a  security  level 
commensurate  with  the  clearance  level  of  the  users  of  the  system.  The  security  level  of  the  system 
shall  be  set  by  a  Network  System  Security  Officer  (NSO)  in  an  assured  manner. 

MLS  computers  shall  have  a  classification  range  (max-min) 
specified  by  the  Network  NSO.  All  data  transmitted  on  the  network  shall  be  labeled  according  the 
classification  set  by  the  NSO.  All  received  data  shall  be  checked  for  label  correcmess  and  only  that 
data  which  has  been  labeled  consistent  with  the  level  of  the  computer  shall  be  received  by  the 
computer. 


c.  Internet 

The  LAN  shall  be  interoperable,  in  a  secure  marmer,  with  wide  area 
networks  (see  WAN  Backbone  below).  The  Internet  shall  provide  this  interoperability  by  using 
routers/gateways  to  provide  assured  relay  of  data  with  assured  label  integrity.  The  router/gateway 
must  accept  a  labeled  network  packet  and  relay  that  packet  without  making  any  changes  to  the  data 
classification  label.  The  Internet  layer  must  be  interoperable  with  current  and  future  DoD  protocol 
suites. 


d.  Wide  Area  Network  Backbone 

The  Wide  Area  Network  (WAN)  Backbone  shall  provide  assured 
mandatory  and  discretionary  access  control  mechaiusms  to  provide  separation  of  classification 
levels  and  need-to-know.  llie  WAN  Backbone  shall  be  DoD  standard  protocol  suite  corrqrliant  - 
TCP/IP  currently,  GOSIP  in  the  future.  It  shall  securely  interoperate  with  the  LAN  and  Internet 
components. 


The  WAN  Backbone  will  be  able  to  support  both  single  level  and 
multilevel  attached  computers.  Single  level  computers  shall  be  treated  at  a  security  level 
commensurate  with  the  clearance  level  of  the  users  of  the  system.  The  security  level  of  the  system 
shall  be  set  by  the  NSO  in  an  assured  manner. 

MLS  computers  shall  have  a  classification  range  specified  by  the 
NSO.  All  data  transmitted  on  the  network  shall  be  labeled  according  to  the  classification  set  by  the 
NSO.  All  rweived  data  shall  be  checked  for  label  correcmess  and  only  that  data  which  has  been 
labeled  consistent  with  the  level  of  the  computer  shall  be  received  by  the  computer. 

The  WAN  Backbone  shall  provide  formal  assurance  proofs  of  the 
correct  operation  of  all  network  security  mechanisms. 

Vn.  SYSTEM  IMPLEMENTATION  PROGRAM  OVERVIEW 

A.  Phasing 

The  proposed  three-part  phasing  of  the  MLS  in5)lementation  is  shown  in  Figure  VII- 
1.  The  near-term  91-93)  and  mid-term  (FY93-95)  phases  provide  for  NTBN  upgrading  to  an 
initial  MLS  capability.  The  long-term  (FY95-99)  ph^e  involves  incorporation  of  features  for 
increasing  MLS  security  assurance. 

In  comparing  NTBN  security  goals  and  requirements  to  predicted  technological 
advances,  great  care  was  ^en  to  be  realistic  and  objective.  It  is  anticipated  that  the  National 
Security  Agency  (NSA)  will  continue  to  place  high  priority  on  evaluating  an  even  greater  number 
of  Computer  Security  (COMPUSEC)  products  at  even  higher  levels  of  COMPUSEC  trust  in  the 
years  ahead.  Increased  assurance  of  secure  operation  is  gained  as  products  evaluated  at  higher 
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levels  of  COMPUSEC  trust  are  incorporated.  The  increased  assurance  is  indicated  by  upgrading 
from  a  B3  level  of  trust  to  an  A1  level.  (B3  and  A1  are  the  technical  terms  used  by  the  NSA  and 
DoD  to  indicate  the  degree  of  trust  (i.e.  assurance  of  secure  operation)  that  a  computer  system  has 
achieved.)  A  system  accredited  at  the  A 1  level  incorporates  security  products  and  safeguards  that 
offer  significantly  higher  levels  of  trust  than  those  needed  for  B3  accreditation,  "nie  NTBN  must 
have  the  highest  possible  degree  of  trust  to  minimize  the  risk  of  security  compromise.  Therefore,  a 
phased  approach  is  recommended  to  achieve  higher  levels  of  assurance  as  the  technology  becomes 
available. 


FBCAL 

YEAR 


Upgrade  To  MLS  Capability 


Increase  Assurance  Of 
Providing  MLS 


Mttito  Bntam  Tfiin 

PiBwwiwiH  TnMiid  Utewki 
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andMW  OS 

Tnwttd 


Proem  £vatuaii 
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Wortutsdona  onHoataand  ofTruaiad 


to  B3  or  A1  to  B3  or  A1 


(1) 


Figure  VII-l.  System  ImplementatiCMi  Program  Overview 

1.  Near-Term  fFY-91-93) 

Near-term  goals  of  the  trusted  MLS  in^lementation  are  to: 

Prepare  design  documentation  and  inqilementation  plans  for  a  first-generation  MLS 
LAN; 


(2)  Inqilement/build  a  trusted  LAN/WAN; 

(3)  Evaluate  trusted  workstations  and  trusted  operating  systems  for  all  hosts  and 
mainframes; 

(4)  Train  all  users  in  use  of  trusted  LANAVAN  resources. 

In  order  to  begin  die  implementation  of  a  ousted  MLS  LAN  in  FY-92  there 
must  first  be  a  detailed  LAN/WAN  design  leading  to  specific  hardware  and  software  specifications. 
This  design  should  be  developed  by  a  follow-on  group  to  the  Tiger  Team,  which  wc«ld 
subsequently  make  recommendations  for  hardware  and  software  procurements.  Installation, 
iynpiffrrtf'.ntarinn,  and  testing  of  the  Qusted  LAN/WAN  should  be  initiated  in  FY-92. 

A  working  group  should  be  formed  in  FY-92  to  evaluate  trusted 
workstation  technology.  A  trusted  workstation  should  be  chosen  (perhaps  more  thai^ne 
typcA^endor)  for  use  on  the  NTBN.  The  workstation  will  become  the  mainstay  of,  and  interface 
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with  the  trusted  LAN;  thus  it  must  be  evaluated  with  regard  to  growth,  evolution,  and 
interoperability.  A  B-rated  technology  such  as  Compartmented  Mode  Workstation  (CMW)  should 
be  the  minimum  level  of  trust  accept^  for  a  workstation  to  access  MLS  LAN  network. 

All  users  of  the  NTBN  must  be  trained  to  use  the  new  MLS  technologies  as 
they  are  implemented.  Such  training  should  include  some  basics  on  NTBN  high-level  design  and 
topology  and  should  also  include  LAN/WAN  operational  procedures  and  computer  security 
practices.  This  training  is  important  to  acclimate  the  users  to  the  MLS  technologies. 

2.  Mid-Term:  rFY-93-95^: 

During  the  mid-term  phase  of  MLS  implementation,  the  following  tasks 
should  be  accomplished; 

( 1 )  Procure  and  implement  trusted  workstations; 

(2)  Evaluate  and  procure  trusted  operating  systems  for  use  on  all  hosts  and  mainframes; 

(3)  Train  personnel  in  the  use  of  trusted  workstations  and  trusted  LAN/WAN 
resources; 

(4)  Evaluate  the  possibility  of  upgrading  the  trusted  network  backbone  (as  technology 
allows). 

During  FY-93,  procurement  of  the  trusted  workstations  should  begin,  and 
by  FY-94,  their  implementation  should  be  fully  completed.  The  implementation  of  trusted 
workstations  should  greatly  increase  the  productivity  of  the  NTBN  users  by  allowing  ease  of 
access  to  a  multiple  array  of  resources  via  the  MLS  network  from  a  single  MLS  workstation. 

The  evaluation  and  procurement  of  trusted  operating  systems  for  use  on  all 
hosts  and  mainframes  should  be  initiated  in  FY-93  and  completed  by  FY-94.  Trust  at  the  B-level 
should  be  the  goal  for  initial  operating  system  implementation  on  the  NTBN.  This  level  of  trust  for 
the  operating  systems  is  consistent  with  implementation  of  B-level  LAN/WAN  technology  and  B- 
level  workstations  with  mandatory  access  control.  Where  this  goal  is  not  feasible  for  initial 
operating  system  implementation,  it  should  continue  to  be  a  longer-term  goal  to  be  achieved  as 
technology  advances.  This  goal  for  B-level  trust  in  operating  systems  should  be  an  on-going 
endeavor,  since  the  intent  of  the  NTBN  is  to  operate  at  the  highest  level  of  trust  technologically 
possible. 


User  training  of  the  trusted  workstations  should  be  initiated  concurrently 
with  their  implementation.  This  training  should  include  all  facets  of  workstation  use  including 
interface  to  the  trusted  LAN/WAN,  Operational  procedures  and  computer  security  practices  should 
also  be  included. 


During  the  mid-term  phase  of  MLS  implementation,  the  possibility  of 
upgrading  the  trusted  network  backbone  (LA^  to  a  higher  degree  of  trust  should  be  investigated. 
If  such  an  upgrade  is  determinwi  to  be  both  feasible  and  necessary,  the  appropriate  budgetary 
programming  should  be  made. 

3.  Long-Term  fFY-95-99): 

Over  the  l(Mig-tenn,  the  MLS  iiiq)lementation  involves  the  following  tasks; 

(1)  Procure  and  implement  trusted  B3  or  A1  operating  systems  for  hosts  and 
mainframes; 
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(2)  Upgrade  trusted  network  backbone  to  B3  or  Al; 

(3)  Upgrade  trusted  workstations  to  B3  or  Al. 

The  long-term  goal  for  the  MLS  implementation  is  to  achieve  the  highest 
degree  of  trust  technologically  possible  within  program  budgetary  constraints.  Procurement  of 
trusted  operating  systems  at  the  B 1  or  B2  level  for  hosts  and  mainframes  should  be  accomplished 
in  FY-93  (during  the  mid-term  phase).  During  FY-95,  these  should  be  upgraded  to  the  B  3  degree 
of  trust.  The  ultimate  goal  for  the  NTBN  should  be  operation  at  the  A 1  security  level.  This  will 
require  implementation  of  an  A 1  certified  network  backbone,  as  well  as  Al  trusted  operating 
systems  for  all  hosts  and  mainframes.  Achievement  of  this  level  of  trust  will  depend  on  the  level 
of  the  available  technology  during  this  period,  as  well  as  the  cost  of  implementing  the  new 
technology.  By  FY-95  or  FY-96  the  operating  systems  available  for  the  trust^  workstations  may 
include  B3  or  even  Al  certified  systems  as  well.  These  systems  should  be  incorporated  as  they 
become  available,  within  budgetary  limitations. 

B.  Functional  Responsibilities 

In  order  for  the  phased  implementation  of  the  MLS  (secure  NTBN)  to  be 
successful,  the  functions  required  to  achieve  that  implementation  must  be  clearly  defined.  The 
functions  vinll  be  the  responsibility  of  the  organizations  which  use  and  maintain  the  NTBN.  Those 
orgaiuzations  are  SDIO,  NTBJPO,  the  NTF,  the  user  organizations  at  the  NTBN  nodes,  and  the 
Executing  Agents  (EAs).  The  functions  relative  to  this  effort  include,  but  are  not  limited  to,  the 
following: 

(1)  Obtain  top-level  program  funding  for  installation,  operations  and  maintenance,  and 
systems  engineering  of  an  operationally  effective  NTB  with  the  proper  security 
safeguards. 

(2)  Ensure  use  of  the  NTB  as  a  common  testing  resource  by  coordinating  NTB 
resources  with  related  SDI  program  requirements. 

(3)  Obtain  a  common  ground  among  different  security  agencies  (DcO,  DOE,  DIS),  so  a 
single  system  can  be  accredited  for  use  by  members  of  all  agencies. 

(4)  Establish  NTBN  interface  requirements  few  all  node  resources  connected  to  the 
NTBN. 

(5)  Engineer,  install,  operate,  and  maintain  the  NTBN  (connect  all  nodes  to  the  NTBN 
backbone). 

(6)  Develop  and  maintain  an  NTBN  standard  interface  for  connecting  NTB  resources  to 
the  NTON. 

(7)  Identify  the  node  resources  to  be  made  available  for  use  by  the  NTB. 

(8)  Provide  guidance/assistance  to  all  nodes  on  ways  to  secure  resources  which 
interface  with  the  NTBN. 

(9)  Maintain  the  resources  (hardware,  software,  personnel)  for  the  centralized 
management,  control,  and  evaluation  of  die  NTBN. 

(10)  Include  NTBN  interface  standards  in  all  contracts  which  require  connectivity  to 
NTB  resources. 
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(11)  Provide  necessary  testing  and  documentation  to  achieve  and  maintain 
accreditation  of  the  NTBN. 

C.  Support  Elements 

Along  with  the  implementation  of  hardware  and  software  components  to  make  an 
MLS  network,  a  support  structure  must  be  developed  to  achieve/evolve  to  an  MLS  operational 
mode  of  the  NTBN.  Support  elements  include  op^dons  and  maintenance,  training,  testing,  and 
system  engineering  of  the  NTBN.  Even  diough  element  support  requirements  will  affect  all  nodes 
to  some  extent  (network  management  and  security  management)  it  is  expected  that  the 
infrastructure  for  these  elements  would  be  provided  by  the  NTB  and  located  at  the  NTF. 
Manpower,  hardware/software  resources,  and  security  clearances  must  be  considered  for  the 
following  task: 

( 1 )  0/M  -  Install  the  selected  components  of  the  MLS  networic 
DevelopAnaintain  the  standard  interface  kits. 

Install  upgrades/improvements  of  network  products  as  they  become 
available. 

Provide  network  hardware/software  configuration  managemenL 
Provide  c^ierational  network  (recemfrguradon)  management 
Provide  network  security  management 

(2)  Training  -  Provide  training  to  support  the  operations  and  maintenance  of 
network  components. 

Provide  training  on  the  use  of  tools  and  the  NTBN  topology  in  support  of 
network/security  management 

Provide  training  to  the  users  of  the  NTB  network.  The  goal  is  to  keep  this 
training  requirement  to  a  minimum  by  providing  a  network  which  is 
transparent  to  the  user. 

(3)  Testing  -  Test  the  network  for  compliance  in  terms  of  usability,  through¬ 
put,  growth,  etc.  This  is  a  recurring  requirement  as  the  network  is 
expanded  and/or  upgraded. 

Test  the  network  to  ensure  proper  use/configuration  of  the  security 
con^nents  of  the  network.  This  is  a  continuing  requirement  to  provide 
additional  assurance  of  the  MLS  capabilities  of  die  network. 

(4)  System  Engineering  -  Develop  the  NTBN  standard  interface  requirements 
using  national  networking/communications  standards. 

Develop  the  NTBN  detailed  designs  in  support  of  all  implementation 
phases. 

Evaluate  new  and  improved  hardware/software  products  to  provide 
increased  assurance/performance  of  network  and  incorporate  selected 
conqxinents  into  the  NTBN  design  as  they  become  available. 
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Provide  engineering  support  to  the  security  accreditation  process. 

Provide  engineering  support  in  the  development  of  node  enhancements  to 
improve  the  NTBN  MLS  capabilities. 

Provide  the  follow-on  engineering  support  to  ensure  compliance  of  the 
Tiger  Team  recommendations. 

D.  FoUow-on  Efforts 

A  working  group  has  been  formed  to  complete  systems  engineering  work  which 
will  provide  the  basis  for  implementing  a  first-generation  MLS  network.  This  wt^ng  group  will 
prepare  an  MLS  Network  Requirements  Document  describing  the  minimum  capabilities  needed  in  a 
first  generation  MLS  network.  The  document  will  also  list  security  and  performance  objectives  for 
future  upgrades  to  the  first-generation  network.  The  working  group  will  also  prepare  an  ^S 
Network  ^ogram  Plan  which  includes  schedule  goals,  estimated  costs,  and  organizational 
responsibilities  for  networic  implementation. 

vni.  CONCLUSIONS 

This  report  recommends  a  multilevel  secure  architecture  to  meet  the  SDI  community’s  need 
.  for  a  data  transfer  network  which  can  restrict  user  access  to  <ia^  baseri  on  a  range  of  security 
considerations  including  clearance  level,  need-to-know,  citizenship  status,  and  corporate 
affiliation.  The  recommendation  was  driven  by  three  key  factors.  First,  a  cost  analysis  showed 
that  it  will  be  prohibitively  expensive  over  the  long  term  to  duplicate  communications  and 
processing  systems  for  each  set  of  NTBN  users  who  are  not  allowed  access  to  the  existing  set  of 
single-level  networks.  Second,  the  proliferation  of  single-level  networks  will  adv^ely  affect 
operation  by  forcing  some  users  to  rely  on  two  or  more  networks  to  perform  a  task  which  could  be 
performed  more  efficiently  on  a  single,  integrated  network.  Finally,  a  technology  survey  showed 
that  components  of  a  first-generation  network  arc  now  commercially  available  as  a  result  of 
recent  industry  and  Government-sponsored  product  development  and  evaluation  efforts. 

The  recommended  NTBN  architecture  meets  user  requirements  identified  in  this  report  and 
provides  a  basis  for  modular  and  flexible  growth  to  accommodate  new  requirements  and 
technologies  as  they  are  identified.  The  selected  architecture  includes: 

(1)  A  LAN  component  which  conforms  to  the  DoD  standard  protocol  suite  and 
supports  secure,  high-speed  communications  with  single  or  multilevel  hosts. 

(2)  An  Internet  component  consisting  of  secure  routers/gateways,  which  support  the 
DoD  protocol  suite  and  secure,  high-speed  communications  with  single  or 
multilevel  hosts. 

(3)  A  WAN  backbone  which  supports  the  DoD  protocol  suite  and  secure 
interconnection  of  NTBN  nodes  through  tiie  LAN  and  Internet  components. 

The  Tiger  Team’s  recommendations  for  implementing  the  recommended  architecture 
include: 

( 1 )  Conqjleting  the  systems  cnginecimg,  design  and  pUuining  activities  required  to  gain 
management  approval  for  procuring  MLS  networking  components. 

(2)  Installing  a  first-generation  MLS  network  in  FY-92  and  performing  p^f-of- 
concept  testing  of  key  elements  of  the  recommended  architecture  and  detailed 
network  design. 
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(3)  Establishing  DAA  MOAs  to  encompass  responsibilities  and  security  policies  for 
protection  of  classified  information  on  AISs  and  the  NTBN. 

(4)  Establishing  an  NTBN  configuration  control  board. 

(5)  Beginning  a  follow-on  effort  to  define  an  approach  for  providing  trusted 
workstations  and  hosts. 
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APPENDIX  A 


Architecture  Evaluation 


I.  INTRODUCTION 

As  described  in  the  body  of  this  report,  there  are  two  major  architectural  network  designs 
that  could  be  employed  to  provide  network  security  for  the  National  Test  Bed:  multiple,  single 
level  networks  or  a  single,  multilevel  secure  (MLS)  network.  This  appendix  provides 
implementation  details  and  cost  estimates  for  these  network  designs. 

A.  Multiple.  Single  Level  Networks 

The  specific  details  of  implementing  the  multiple,  single  level  networks  architecture 
are  well  known  to  the  NTB  community  because  this  is  the  current  NTB  network  architecture,  A 
number  of  additional  networks  and  computers  will  be  required  if  this  architecture  is  to  continue  to 
support  all  of  the  classifications  and  compartments  needed  for  the  future  NTBN. 

This  architecture  would  make  use  of  separate,  isolated  facilities  to  support  usere  at 
specific  clearance  levels.  Each  of  the  separate  networks  would  need  its  own  communications 
system  to  provide  intercoimectivity  between  NTBN  sites.  Users  with  specific  clearaiice  levels  will 
be  located  at  various  NTBN  sites  and  will  need  access  to  various  types  of  computing  resources. 
Communications  security  (COMSEC)  equipment  will  be  necessary  to  ensure  the  confidentiality  of 
data  transmitted  between  sites. 

The  majority  of  security  mechanisms  and  features  employed  in  this  architecture  are 
related  to  physical  security  rather  than  system  security.  Users  would  have  physical  access  to 
terminals,  workstations,  and  computers  that  are  connected  to  the  network  that  contains  data  at  the 
user's  clearance  level.  Therefore,  for  example,  users  who  have  a  secret  clearance  would  only  have 
physical  access  to  the  secret  network  and  its  facilities.  They  would  not  be  allowed  access  to  any 
other  network’s  facilities.  Physical  access  control  to  the  facility  can  be  accomplished  in  several 
manners  such  as  by  having  guards  checking  facility  access  lists,  by  badge  readers  connected  to 
facility  access  computers  that  check  access  control  lists,  or  biometric  checking  equipment  (retina 
scan,  fingerprint,  voice  print)  connected  to  facility  access  computers. 

Security  policy  typically  allows  data  to  flow  up  fiom  a  lower  classification  level  to  a 
higher  classification  level.  In  this  manner,  a  Secret  cleared  user  has  the  ability  to  read  all  the  data  at 
his  level  and  below  without  a  security  compromise.  However,  with  multiple,  single  level 
networks  that  are  totally  isolated,  the  user  will  not  have  the  ability  to  read  any  data  except  at  the 
specified  clearance  level.  In  order  for  data  to  flow  up,  one-way  gateways  could  be  used  to  allow 
the  interconnection  of  the  single  level  networks.  The  one-way  gateways  would  provide  high 
assurance  that  data  will  flow  only  in  one  direction,  fiom  low  to  high  and  that  there  will  be  no  data 
flow  from  high  to  low.  In  effect,  the  gateway  acts  as  a  diode,  allowing  flow  in  one  direction  only. 
There  are  several  candidate  systems  implemented  with  high  assurance  security  reference  monitors 
that  could  be  used  to  build  such  a  gateway  (HFSI XTS-200,  Gemini,  Loral  MLS- 100).  Although 
several  of  the  systems  are  NCSC  evaluated  (or  soon  to  be),  the  gateway  application  would  have  to 
be  separately  evaluated  and  shown  to  provide  the  necessary  assurances  with  respect  to  data  flow. 
It  would  then  be  up  to  the  Designated  Approving  Authority  to  decide  whether  to  allow  such 
interconnection  among  the  various  single  level  networks. 

The  costs  associated  with  multiple,  single  level  networks  can  be  determined  by  the 
number  of  networks  needed,  the  computing  resources,  the  physical  security  controls,  and  the 
administration  and  operations  personnel  that  need  to  be  duplicated  among  those  networks.  As 
previously  described  in  Section  VI,  if  users  on  each  separate  network  require  simultaneous  access 
to  a  CRAY,  then  a  CRAY  would  have  to  be  procured  for  each  network  at  the  current  pnee  of  a 
CRAY.  In  addition,  operators  for  each  CRAY,  for  each  network  control  center,  and  for  all  of  me 
other  computing  resources  would  be  required.  Table  A-1  provides  cost  estimates  for  purchasmg 
and  operating  six  new  Cray  computer  systems  as  part  of  separate,  single-level  networks. 
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Table  A- 1 .  Cost  Estimate  For  Six  Cray  Systems  As  Part  Of  Multiple  Single-Level  Networks 


Cost 

Item 

Nonrecurring 

Cost 

Recurring 
Cost  (Annual') 

Computer  Systems 

HW/SW 

$110  M 

Communications  Systems 

$3.3M 

ADPA  Operational  Support 

$2.6M 

Vendor  Maintenance  Support 

$5.4M 

External  (Circuits 

$  8.8  M 

TOTAL 

$113.3  M 

$16.8  M/YR. 

B.  Single.  Multilevel  Secure  Network 

A  single  multilevel  secure  network  is  a  major  departure  from  the  existing  NTB 
architecture.  The  MLS  network  will  require  the  use  of  network  components  that  do  not  degrade 
current  network  performance,  are  reliable,  maintainable,  and  provide  assurance  of  correa  operation 
with  respect  to  security  enforcement  mechanisms.  The  assured  operation  of  security  mechanisms 
is  the  basis  upon  which  the  network  is  trusted  to  provide  data  separation,  based  on  data 
classification,  on  the  network.  The  MLS  network  will  use  components  which  have  been  designed 
and  developed  in  compliance  with  NCSC  guidelines.  The  types  of  components  under 
consideration  here  are  network  security  interface  devices,  network  security  front-end  devices, 
routers/gateways,  bridges,  packet  switching  equipment,  and  COMSEC  devices. 

In  the  near-term,  a  single,  multilevel  secure  network  can  be  built  using  existing, 
commercially  available  network  security  products.  These  current  products  implement  computer 
securi^  features  and  mechanisms,  but  are  lacking  in  the  area  of  high  assurance  of  correct 
operation.  An  example  MLS  network  of  this  type  is  the  Verdix  Secure  Local  Area  Network 
(VSLAN)  which  has  been  evaluated  by  the  NCSC  and  rated  at  the  B2  (MDIA)  level.  This  rating 
indicates  that  the  VSLAN  provides  mandatory  and  discretionary  access  control  (MAC/DAC)  as 
well  as  identification,  authentication  and  auditing.  However,  at  the  B2  level,  there  are  no 
requirements  for  design  or  implementation  assurance  of  correcmess  of  operation.  Without  such 
assurance,  the  number  of  classification  levels  that  can  simultaneously  be  supported  on  the  same 
network  is  limited  (ref  Yellow  Book).  These  limitations  will  be  discussed  furtier  in  the  following 
paragraphs. 


For  the  long-term,  the  NTB  should  utilize  MLS  components  that  provide  high 
assurance  of  correct  security  operation.  These  high  assurance  products  provide  the  same  base 
security  functionality  as  do  Aeir  low  assurance  counterparts,  but  provide  the  additional  assurance 
that  those  security  functions/mechanisms  operate  as  they  were  designed,  with  no  additional 
functional  or  side  effects  that  could  compromise  system  security. 
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The  VSLAN  is  an  lEKF  802.3  (Ethernet)  LAN.  The  evaluated  components  of  the 
VSLAN  are  the  Verdix  Network  Security  Device  (VNSD)  and  the  Verdix  Network  Security 
Controller  (VNSC)  as  shown  in  Figure  A-1.  The  VNSC  is  Ae  security  officer  operations  center 
Aat  provides  Ae  NSO  wiA  Ae  tools  for  mitializing,  administering,  and  controlling  Ae  network. 
The  VNSDs  are  hardware  boards  Aat  are  installed  m  each  of  Ae  network  computers  and  are 
controlled  by  Ae  VNSC.  Verdix  currently  produces  boards  for  many  computer  bus  configurations 
(e.g.,  QBus,  VME,  Multibus,  PC-AT)  and  has  several  more  under  development 

The  VNSDs  are  MLS  trusted  devices  that  operate  wiA  a  security  kernel  running  on 
an  Intel  286  processor  on  Ae  VNSD  board.  The  VNSDs  are  defined  by  Ae  VNSC  to  be  operating 
at  a  specific  security  level  (when  installed  in  a  smgle  level  computer)  or  at  a  range  of  levels  (when 
mstalled  m  a  multilevel  computer).  Source  and  destination  computer  systems  are  identified  and 
auAenticated  by  Ae  use  of  DES  encryption  and  a  datakey  msened  mto  a  receptacle  connected  to  Ae 
VNSD  board. 

A  VSLAN  NSC  can  control  128  computers  on  a  secure  network  se^ent.  In  order 
to  provide  connectivity  for  more  computers,  as  well  as  to  computers  at  remote  sites  (e.g.,  NTF, 
SDC,  GE)  a  router/gateway  device  is  needed.  The  VerAx  Secure  IP  Router  (VSIP)  is  a  secure 
router  Aat  is  able  to  securely  mteiconnect  two  VSLANs  or  can  mterconnect  a  VSLAN  and  a  smgle 
level  EAemet  This  device  can  be  used  to  mterconnect  networks  m  a  local  facility  such  as  Ae  NTF 
or  between  facilities  using  COMSEC  devices  to  provide  confidentiality  on  Ae  transmission 
meAum. 


Figure  A-1.  Smgle  MLS  Network  Using  Verdix 


Using  a  VSLAN  architecture,  several  classification  levels  can  be  combined  onto  a  single  MLS 
network.  Because  the  VSLAN  is  rated  B2,  not  all  the  required  classification  levels  can  be 
combined  onto  the  same  network.  This  is  a  result  of  the  risks  that  are  involved  in  using  network 
components  that  do  not  provide  high  levels  of  assurance  of  operation.  The  Guidance  For  Applying 
the  Department  of  Defense  Trusted  Computer  System  Evaluation  Criteria  in  Specific  Environments 
(CSC-STD-(X)3-85,  sdso  called  the  Yellow  Book)  provides  guidance  in  deciding  how  many  levels 
of  classification  can  be  combined  on  an  MLS  system  based  on  its  evaluation  rating.  Using  Yellow 
Book  guidance,  all  of  the  Secret  level  networla  and  the  Top  Secret  networks  could  be  combined 
using  a  B2  network,  but  Unclassified  users  would  have  to  be  kept  separate  or  connected  via  a 
special,  high  assurance  gateway.  Only  witii  a  system  that  provides  higher  assurance  of  coirecmess 
could  more  levels  be  simultaneously  connected.  However,  this  architecture  does  succeed  in 
eliminating  most  of  the  replicated  networks. 

VSLAN  implementation  costs  are  variable.  Each  PC  or  workstation  could  have  a 
VNSD  board  inserted  for  attachment  to  the  network  (at  a  cost  of  $4250  per  board  in  single 
quantities  with  volume  discounts  available),  or  communities  or  PCs  and  workstations  could  be 
connected  as  a  single  level  community  of  interest  using  a  router  onto  the  secure  network 
backbone.  Each  mainframe  system  would  have  a  VNSD  board  (if  available  for  the  specific 
processor)  or  could  have  a  VNSD  in  a  front-end  system  (e.g.,  a  SUN  front-ending  a  CRAY).  The 
Verdix  Secure  IP  Router  costs  $12,000  and  a  Verdix  Network  Security  Controller  costs  $17,5()0. 
The  total  implementation  cost  would  be  determined  by  the  final  network  topology  which  would 
result  in  a  determination  of  how  many  copies  of  each  device  would  be  required.  As  an  example,  if 
there  were  200  computers  that  were  to  be  directly  connected  to  the  VSLAN  (e.g.,  VNSD  boards 
directly  insened  into  their  backplanes)  the  cost  would  be  no  greater  than  $850,000  (acmal  cost 
would  be  lower  based  on  volume  discounts).  In  addition  at  least  two  VNSCs  would  be  needed 
since  each  VNSC  controls  up  to  128  attached  computers.  Therefore,  there  is  an  additional  cost  of 
$35,0(X).  There  would  also  be  a  need  for  sever^  VSIP  (routers)  devices  (approximately  10), 
resulting  in  additional  cost  of  $120,000.  Therefore,  for  these  strawman  numbers,  a  total 
installation  of  VSLAN  hardware  products  would  cost  approximately  $1.05  million.  There  would 
be  additional  charges  for  communications  lines  interconnecting  the  NTB  sites.  Hiis  can  be 
compared  to  the  cost  of  replicating  a  network  many  times  (including  the  $90  million  for  replicated 
CRAYs)  and  it  appears  to  be  a  very  good  maimer  in  which  to  proceed  to  save  large  amounts  of 
money. 


An  alternative  MLS  architecture  can  utilize  the  Government-developed  BLACKER 
family  of  network  security  equipment  as  shown  in  Figure  A-2.  BLACKER  products  are  currently 
available,  and  products  from  Ac  related  CANEWARE  program  will  be  available  in  FY1992. 
BLACKER  has  been  evaluated  by  Ac  NCSC  and  has  been  given  an  A1  rating.  CANEWARE  will 
be  evaluated  as  a  B2  device.  In  addition,  BLACKER  has  been  evaluated  from  a  COMSEC 
perspective  and  is  endorsed  as  a  high  grade.  Type  1  cryptolographic  equipment  BLACKER  has 
been  certified  for  use  by  Ae  Defense  Data  Network  (DDN)  to  combine  its  three,  separate  classified 
DISNET  networks  (SECRET,  TS,  and  TS/SCI)  mto  one  network  sharing  a  common  backbone. 
BoA  BLACTCER  and  CANEWARE  were  designed  to  operate  over  packet  switched  networks  and 
interface  to  Packet  Switching  Nodes  (PSN).  BLACKER  mterfaces  to  PSNs  using  Ae  DDN-X.25 
standard  and  CANEWARE  uses  Ae  DDN-X.25  or  Ccn  i-X.25  standards.  BLACKER  will  run 
at  64  KBits/second  and  CANEWARE  will  run  up  to  T1  mterface  speeds  (1.544  Mbits/second). 


In  a  BLACKER  architecture,  the  network  interface  of  a  host  or  community  of  hosts 
would  be  a  BLACKER  Front  End  (BFE)  device.  The  BLACKER  would  provide  access  control, 
source-to  destination  identification  and  authentication,  and  data  confidentiality.  Because 
BLACKER  is  rated  Al,  there  is  less  risk  in  combining  different  classificadon  levels  than  with  a  B2 
system.  The  Al  rating  signifies  that  the  design  was  formally  specified  and  that  rigorous  proofs 
have  been  performed  to  provide  evidence  that  die  system  ope^es  correctly.  Unclassified  through 
Top  Secret  is  sdll  not  advised  (based  on  the  Yellow  Book),  but  Al  does  allow  confidendal  users  to 
be  added  to  the  network  with  Top  Secret  or  even  multiple  Top  Secret  compartments. 
CANEWARE,  when  it  is  available,  will  provide  higher  line  speeds  than  BLACKER. 

To  implement  an  MLS  network  using  BLACKER  (or  CANEWARE)  equipment,  a 
packet  switching  network  must  first  be  procured  and  installed.  The  packet  switching  network 
could  be  a  technology  copy  of  the  DDN  using  Bolt,  Beranek,  and  Newmaim  (BBN)  DDN  Packet 
Switching  Nodes,  ^temadvely,  die  DDN  DISNET  could  be  used  as  the  interconnection  medium 
between  NTB  sites.  Hosts  would  be  connected  to  BLACKERs  which  in  turn  would  connect  to 
PSNs.  BLACKER  makes  use  of  an  Access  Control  Ctnva  to  make  mandatory  (classification)  and 
discretionary  (need-to-know)  access  control  decisions.  A  Key  Distribution  Center  is  used  to 
distribute  cryptolographic  keys  based  on  a  source/destination/classification  connection  basis. 

BLACKER  devices  cost  approximately  $10,000  each,  not  including  installation. 
To  effectively  use  BLACKER,  the  network  topography  should  make  extensive  use  of  single  or 
multilevel  level  local  area  networks  that  would  be  gatewayed  through  a  BLACKER  onto  the  MLS 
network  backbone.  In  this  way,  the  number  of  BLACKERs  required  would  be  minimized  without 
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effecting  the  overall  security  of  the  MLS  networic.  If  the  NTB  were  to  need  100  BLACKERs,  the 
cost  would  be  approximately  $1  million.  In  addition,  packet  switching  equipment  would  be 
needed  at  each  of  the  sites.  A  BBN  C/30  packet  switch  costs  approximately  $30,000.  A  20- 
switch  network  would  cost  $600,000.  In  addition  there  would  h«  charges  for  network  usage 
(e.g.,  DISNET  charges  of  $60,000  per  year  or  private  line  charges  if  DISNET  were  not  used  to 
interconnect  the  sites). 

Another  alternative  architecture,  as  already  alluded  to  in  the  previous  paragraph,  is 
the  combination  of  secure  LAN  and  BLACKER/CAI^WARE  products  as  shown  in  Figure  A-3. 
The  LAN  products  are  typified  by  providing  higher  throughput  speeds  than 
BLACKER/CANEWARE.  In  this  manner,  the  local  users  at  a  specific  site  can  enjoy  the  higher 
speeds  afforded  by  using  Ethernet  or  fiber  cable  plants  and  only  use  the  lower  speed 
interconnections  when  going  between  sites.  A  current  problem  in  using  this  architecture  is  the 
inability  of  the  current  generation  Veidix  devices  to  allow  a  security  label  to  be  exported  to  a  non- 
Verdix  network.  A  Verdix  Secure  IP  Router  with  a  non-VSLAN  interface  (Ethernet)  would  not 
expon  a  label.  The  LAN  would  treat  the  Ethernet  as  a  single  level  network.  This  would  be  true 
even  if  a  multilevel  BLACTKER  were  on  the  other  side  of  the  Ethernet  A  secure  router  would  have 
to  be  designed  and  built  to  provide  this  MLS  connectivity  across  networks.  The  VSIP,  Gemini, 
Loral,  or  HFSI  equipment  could  be  used  as  secure  gateway  platforms  to  perform  this  function. 


NTB  NETWORK  Security  Architecture 
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EXECUTIVE  SUMMARY 


A.  INTRODUCTION 

The  "NTB  Network  Security  and  Communications  Report"  completed  by  the  National  Test 
Bed  (NTB)  Security  and  Communications  Architecture  Working  Group  (SCAWG  -  also  called  the 
"Tiger  Team")  provided  the  definition  of  a  system  architecture,  operational  concept,  and  system 
implementation  approach  to  provide  secure  and  integrated  information  transfer  and  shared 
computing  capabilities  to  support  the  NTB  mission.  These  capabilities  will  be  achieved  by 
evolution  of  the  existing  National  Test  Bed  Netwoik  (NTBN)  and  NTBN  nodes. 

The  Tiger  Team  began  its  work  in  March  1991  and  met  regularly  for  five  months.  Initial 
Tiger  Team  efforts  focused  on  identifying  system  r^uirements  and  investigating  available 
technologies  in  the  areas  of  security,  automated  information  systenis  (AIS)  interfaces, 
communications,  and  control.  The  Tiger  Team  evaluated  alternative  architectures,  operational 
concepts,  and  implementation  approaches  based  on  their  projected  cost  and  responsiveness  to 
system  requirements. 

The  Tiger  Team  report  recommended  a  multilevel  secure  architecture  to  meet  the  SDI 
community's  need  for  a  data  transfer  network  which  can  restrict  user  access  to  data  based  on  a 
range  of  security  considerations  including  clearance  level,  need-to-know,  citizenship  status,  and 
corporate  affiliation.  The  recommendation  was  driven  by  three  key  factors.  First,  a  cost  analysis 
showed  that  it  will  be  prcrfiibitively  expensive  over  the  long  term  to  duplicate  communications  and 
processing  systems  for  each  set  of  NTB  users  who  are  not  allowed  access  to  the  existing  set  of 
single-level  networks.  Second,  the  proliferation  of  single-level  nctworics  will  adversely  affect 
operations  by  forcing  some  users  to  rely  on  two  or  more  networks  to  perform  a  task  which  could 
more  efficiently  be  performed  on  a  single,  integrated  network.  Finally,  a  technology  survey 
showed  that  components  of  a  first-generation  Multilevel  Secure  (MLS)  network  are  now 
commercially  available  as  a  result  of  recent  industry  and  Government-sponsored  product 
development  and  evaluation  efforts. 

This  report  builds  upon  the  Tiger  Team  report  and  extends  the  architecture  to  include  both 
MLS  communications  and  computing.  It  describes  an  MLS  Network  security  architecture  and 
provides  the  guidance,  requirements,  and  recommendations  necessary  to  commence  the  design, 
development,  and  implementation  of  an  MLS  Network  to  support  the  communications  and 
computing  needs  of  the  SDI  community.  It  includes  a  phased  in^lementation  of  secure  interface 
units  starting  at  the  NTF  LAN,  progressing  to  the  I^N,  and  finally  to  implementation  of  secure 
operating  systems  and  applications  on  selected  mainframes  and  workstations.  It  includes  the  use 
of  prototyping  during  the  near  term  to  ensure  the  success  of  later  phases. 

B.  SEniRlTY  GOALS 

The  need  for  security  in  the  NTB  environment  is  dictated  by  the  sensitivity  of  information 
and  the  internal  and  external  threat  of  compromise  of  that  information.  Security  as  such  is  an 
enabling  technology  which  provides  a  wide  range  of  users  access  to  shared  computer  Md 
communication  resources  which  process  information  at  multiple  levels  of  classificatiOT.  The 
challenge  in  providing  the  needed  security  is  defined  by  the  environment  within  which  the  NTB 
missiwi  must  be  perfarmed.  The  key  elements  of  tiie  mission  environment  include: 

(1)  Dispersed  geography  with  many  AIS  platforms  and  many  requirements  to 
ctxnmunicate; 
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(2)  A  wide  range  of  users  from  Government,  industry,  and  various  U.S.  Allies;  and 

(3)  A  wide  range  of  security  classification  levels  required. 

The  fundamental  security  goal  is  therefore  to  suppon  the  simultaneous  accessing  and 
processing  of  Unclassified,  Unclassified  Sensitive,  and  Classified  SDI  data  by  a  wide  range  of 
users  with  different  secimty  clearances  and  authorizations.  The  specific  security  requirements  for 
access  restrictions,  data  integrity,  user  identification  and  accountability,  and  system  integrity  must 
be  resolved  to  successfully  achieve  this  goal.  The  MLS  Network  will  be  achieved  through  a 
phased  implementation  consisting  initially  of  currently  available  trusted  components  for  the  near 
term  MLS  NTF  LAN  (FY92-93),  with  a  planned  migration  path  through  the  mid  term  h'flLs  NIBN 
(FY93-95),  to  the  long  term  h^S  NTBN  and  NTBN  nodes  (FY96-99).  Current  and  projected 
security  products  and  technologies  will  be  incorporated  to  fully  meet  all  security  requirements  and 
objectives. 

C.  SUMMARY  OF  REQUIREMENTS 

Access  to  data  must  be  restricted  to  only  those  users  who  are  appropriately  authorized  for 
that  data.  Authorizations  shall  be  based  on  a  user's  security  clearance,  need-to-know,  and 
restrictions  resulting  from  organizational  conflicts  of  interest  and  a  user's  citizenship.  To  meet  the 
projected  user  requirements  and  to  enhance  the  current  capabilities,  the  MLS  Network,  and  in 
particular  the  NTF  LAN  and  the  NTBN  must  support  an  MLS  mode  of  operation.  The  MLS 
requirement  is  directly  driven  by  the  SDI  requirement  to  "provide  a  common  test  environment  for 
the  desi^  of  GPALS",  and  by  the  wide  participation  of  Government,  academic,  industry,  and 
allied  nation  organizatiems. 

The  requirement  for  flexibility  is  derived  from  both  the  changing  mission  environment  and 
the  evolution  of  test  phases  as  cited  by  the  SDIO  user  community.  The  mission  environment  is 
altered  by  the  redirection  of  SDIO  toward  theater  and  tactical  considoations  which  in  turn  may  alter 
the  required  geographic  dispersion  of  supporting  NTB  resources.  The  evolution  of  test  phases 
indicate  that  many  of  the  programs  in  SDIO  are  still  in  the  early  stages  of  development,  and  as 
development  progresses  test  complexity  and  scope  will  expand.  New  sites  will  be  a^ed  and  must 
be  accommoda^ 

The  requirement  for  modularity  follows  the  derivation  of  the  r^uirement  for  flexibility,  and 
the  need  to  support  a  shared  resource  user  community.  With  a  dynamic  user  ctxnmunity  accessing 
a  shared  resource,  a  common  set  of  mechanisms  for  providing  that  access  is  essential  for 
responsiveness.  A  modular  api^ach  allows  the  network  to  easily  adapt  to  varying  data  capacity 
and  security  requirements,  malang  resources  available  as  they  are  ne^ed.  Thus  modularity  is  a 
critical  charkheristic  that  must  be  incorporated  in  a  responsive  security  architecture. 

The  need  for  standardization  (and  conformance  to  a  guiding  set  of  standards)  derives  from 
the  dynamic  nature  of  the  NTB  user  community  and  from  public  law,  DoD  policy,  and  federal 
policy.  Standardization  of  security  mechanisms,  communications  mechanisms,  and  operational 
proc^ures  will  be  essential  to  maintaining  a  res^nsive  MLS  Network  over  its  life  cycle.  The 
selection  of  a  gmding  set  of  standards  for  the  architecture  is  driven  by  this  need  for  supportability 
and  maintainability;  however,  it  is  also  recognized  that  standards  in  communications  and  security 
are  still  evolving  and  thus  the  architecture  must  be  flexible  enoii^  to  evolve  with  those  standards. 
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D.  SUMMARY  OF  RESULTS 

To  achieve  the  security  goal,  an  MLS  Network  that  will  preserve  the  integrity  of  sensitivity 
labels  and  use  those  labels  to  enforce  mandatory  access  controls  based  on  the  differing  clearance 
levels  and  authorizations  of  individual  NTB  users  must  be  developed  and  implemented  in 
accordance  with  the  computer  security  requirements  specified  in  DOD  52(X).28-STp,  DOD  Trusted 
Computer  System  Evaluation  Criteria.  Based  on  the  determination  and  application  of  the  Risk 
Index  to  the  MLS  Network  security  components  in  accordance  with  the  guidance  provided  in  CSC- 
STD-003-85,  "Application  of  Computer  Security  Requirements  In  Specific  Environments",  for 
"closed"  security  environments,  the  near  term  (FY92-93)  requires  a  class  B2  level  of  assurance  as 
a  minimum,  the  mid  term  (^93-95)  requires  a  class  B3  level  of  assurance  as  a  minimum,  and  the 
long  term  (FT96-99)  requires  a  class  A1  level  of  assurance  as  a  minimum.  The  Risk  Index  is  an 
indication  of  the  disparity  between  the  minimum  clearance  or  authorization  of  users  and  the 
yn^Yimiim  sensitivity  (e.g.,  classification  and  categories)  of  data  processed  by  the  MLS  Network. 

A  number  of  factors  were  considered  in  designing  the  security  architecture  to  meet  the 
required  levels  of  assurance.  First  and  foremost,  the  security  components  must  comply  with  all 
specified  security  requirements.  Second,  to  ensure  affordability,  the  security  components  must  be 
National  Security  Agency  (NSA)  evaluated/certifiable  commercial-off-the-shelf  (COTS)  trusted 
security  products  to  the  maximum  extent  possible.  Finally,  a  cost  effective  and  well  planned 
migration  path  must  be  provided  to  transition  fiom  the  near  term  to  the  long  term. 

The  security  aiohitectuie  addresses  all  these  factors  and  related  issues  by  initially  providing 
a  minimum  of  a  B2  MLS  NTF  LAN  in  the  near  term.  There  are  two  distinct  approaches  for 
achieving  the  B3  mid  term  and  A1  long  term  requirements.  The  first  approach  is  the  modular 
replacement  of  B2  evaluated  components  with  NSA  evaluated/certifiable  B3/A1  components,  “^e 
second  and  recommended  approach  is  to  select  A1  evaluatcd/certifiable  con^nents  fw  use  starting 
in  the  near  term.  To  facilitate  either  approach,  the  security  architecture  must  be  design^  from  Ae 
beginning  to  meet  A1  requirements,  liiis  will  be  accomplished  by  developing  the  initial  security 
ESSUTEnce  docuincnts  (philosophy  of  protection,  and  infonnal  and  foxmal  security  policy  models) 
to  meet  A1  requirements,  designing  the  security  architecture  based  on  the  A 1  security  policy 
model,  and  nxxlularly  partitioning  the  design  to  facilitate  the  use  of  additional  A1  products  as  they 
become  available. 

In  addition  to  meeting  all  computer  security  r^uirements.  Communications  Security 
(COMSEC)  and  TEMPEST  countermeasures  will  be  impletrrented  in  accordance  with  SDIO 
Directive  5206,  established  regulations,  directives  and  procedures.  Likewise,  physical  and 
procedural  security  will  be  implemented  in  accordance  with  the  appropriate  guidelines. 

E.  CONCLUSIONS 

To  support  the  simultaneous  access  of  information  with  different  sensitivities  by  users  wth 
different  clearances  and  need-to-know,  and  to  prevent  users  from  obtaining  access  to  info^tion 
for  which  they  lack  authorization,  the  MLS  Network  must  enforce  Mandatory  Access  Control 
(MAC)  and  Discretionary  Access  Control  (DAC).  The  near  term  security  operating  mode  will  be 
l^S  and  will  initially  require  a  minimum  of  a  B2  level  of  assurance  to  support  us^  with  a 
minimiiTn  clearance  of  Secret  and  to  simultaneously  process  Unclassified  and  Classified  (up  to 
Secret  with  multiple  categories)  information.  In  the  near  term,  the  NTF  LAN  will  tyerate  in^ 
MLS  mode  and  will  simultaneously  support  multiple  communities  of  interest  located  at  the  NTF. 
A  community  of  interest  is  a  closed  user  group  that  permits  users  belonging  to  a  group  to 
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communicate  with  each  other,  but  precludes  communications  with  other  users  who  are  not 
members  of  the  group.  i 

The  mid  term  MLS  NTBN  security  operating  mode  will  also  be  MLS,  but  will  require  a 
minimum  of  a  B3  level  of  assurance  to  support  users  with  a  minimum  clearance  of  Secret  and 
simultaneously  process  Unclassified  and  Classified  (up  to  Top  Secret  with  multiple  categories) 
information.  In  the  mid  term,  in  addition  to  the  MLS  NTF  LAN,  the  MLS  NTBN  will  provide 
simultaneous  support  and  access  to  NTF  resources  to  users  at  the  other  NTBN  nodes  operating  in 
different  communities  of  interest.  The  remote  NTBN  nodes  will  still  operate  as  single  level 
communities  of  interest. 

The  long  term  MLS  NTBN  and  NTBN  nodes  will  require  a  minimum  of  an  A1  level  of 
assurance  to  support  users  with  no  clearance  and  simultaneously  process  both  Unclassified  and 
Classified  (up  to  Top  Secret  with  multiple  categories)  information.  During  the  long  term,  the 
network  will  provide  for  MLS  access  to  databases  and  computing  resources  and  some  of  the 
NTBN  nodes,  other  than  the  NTF,  will  operate  in  the  MLS  mode. 


iNCSC-TG-005,  Version  1,  pg  264. 
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INTRODUCTION 


This  document,  which  is  derived  from  the  Tiger  Team  recommendations  and 
conclusions,  provides  guidance  and  requirements  for  the  next  phase  in  the  design,  development, 
and  implementation  of  an  MLS  Network.  The  architecture  and  implementation  proposed  extend 
the  definition  of  a  solution  to  the  problems  (high  cost,  restricted  data  exchange  between 
communities  of  interest  (COIs),  and  limited  resource  sharing)  associated  with  the  continued 
proliferation  of  dedicated  mode  networks,  nodes,  and  AISs.  The  MLS  Network  will  evolve  from 
the  existing  system  high  NTBN  and  dedicated  and  system  high  NTBN  nodes. 

This  document  consists  of  seven  sections  and  four  attachments:  Section  I,  Introduction, 
defines  the  scope  and  objectives  of  the  document  and  provides  background  information  on  the 
Tiger  Team  report  and  its  conclusions.  Section  11,  Derinitions,  provides  a  set  of  basic  working 
definitions  us^  throughout  the  remainder  of  the  document  These  definitions  establish  the 
framewoiic  for  the  architecture  by  specifying  the  characteristics  of  an  MLS  Network  and  its 
security  components.  Section  m,  Ne^  for  MLS  Communications  and  Computing  Environment, 
provides  an  overview  of  the  requirements.  Section  IV,  Evolutionary  Approach,  describes  the 
changes  to  be  made  as  the  NTBN  and  NTBN  nodes  evolve  from  the  existing  Secret/CW  system 
high  NTBN  and  dedicated  and  system  high  NTBN  mode  nodes  to  the  MLS  m<^e  network. 
Section  V,  Requirements,  contains  the  functional,  performance,  and  security  requirements  for  the 
near,  mid,  and  long  terms.  Section  VI,  Security  Architecture,  identifies  and  Ascribes  the  projected 
modes  of  operation  of  various  components  during  the  three  phases,  describes  "risk  index”  and 
"open"  and  "closed”  environments  and  their  relationships,  shows  the  computation  and  derivation 
of  the  level  of  trust  requirements,  and  contains  figures  showing  allowable  data  transfers  and  COI 
segregation.  Section  Vn,  Preliminary  Implementation  Architectures,  describes  the  use  of  secure 
interface  units  to  segregate  data  based  upon  COI  and  contains  figures  which  show  equipment 
configurations  that  produce  an  MLS  NIT  LAN,  NTBN,  and  AISs  in  the  near,  mid,  and  long 
terms,  respectively.  Attachment  I,  Boeing  Secure  Network  Server  (SNS)  and  Network  Manager 
(NM)  Capabilities,  describes  the  SNS  and  NM.  Attachment  11,  Security  Engineering  Process, 
describes  the  documentation,  engineering,  and  testing  that  will  be  requir^  to  evolve  &e  NTBN 
and  NTBN  nodes  to  MLS  mode.  Attachment  III,  MLS  Network  Proto^ing  Plan,  provides  the 
schedules,  estimated  resources  and  prototyping  methodology  to  be  used  in  the  development  of  an 
initial  prototype  and  the  phased  enhancements  to  the  initid  prototype  necessary  to  support  the 
implementation  and  migration  ftom  the  near  term  to  the  long  term  envircmments.  Attachment  IV, 
NTB  Security  Strategy  Working  Group  Repeat,  addresses  the  development  of  the  NTBN  Security 
Architecture. 

A.  Scope  and  Objectives 

This  document  provides  guidance  and  identifies  the  requirements  for  implementing  a  first 
generation  MLS  Network  in  the  near  term  that  provides  support  to  NTB  users  with  a  minimum  of  a 
Secret  clearance  simultaneously  operating  in  multiple  COIs.  In  addition,  it  provides  guidance  and 
requirements  for  the  evolution  of  the  N&S  NTBN  and  NTBN  nodes  in  die  mid  and  long  term 
timeframes.  The  long  term  objective  is  to  i^vide  the  capability  for  simultaneous  connectivity  for 
uncleared  and  cleared  users  with  data  sensitivity  levels  ranging  from  Unclassified  to  Top  Secret 
with  multiple  categories. 

B.  Background 

The  NTB  Security  and  Communications  Architecture  Working  Group  (SCAWG  -  also 
called  the  "Tiger  Team")  report  provides  a  definition  of  an  architecture,  operational  concept,  and 
implementation  approach  to  provide  secure  and  integrated  information  transfer  and  shared 
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computing  capabUities  to  support  the  NTB  mission.  The  Tiger  Team  report  recommend^  that  the 
MLS  Network  evolve  froni  the  existing  system  high  NTBN  and  dedicated  and  system  high  mode 

NTBN  nodes. 

The  Tiger  Team  began  its  work  in  March  1991  and  met  regularly  for  five  months.  Initial 
Tiger  Team  efforts  focused  on  identifying  system  level  requirements  and  investigating^ailable 
technologies  in  the  areas  of  security,  AIS  interfaces,  communications,  and  control.  The  Tipr 
Team  evaluated  alternative  architectures,  operational  concepts,  and  implemen^on  approaches 
bas^  on  their  projected  cost  and  responsiveness  to  system  level  requirements.  Tne  Tiger  Team  s 
recommendations  were  approved  by  representatives  of  the  Government  organizations  and  support 
SSorCovern^iint  roprosenmti^^^  included  SDIO/POI,  SDIO/SIS,  SDIO/SDA,  SDICySDT 
(NTBJPO),  USASDC,  and  NSA.  Contractor  representatives  included  BDM  International  Inc, 
Beta  Analytics  Inc,  General  Electric,  MiTKE,  Martin  Marietta,  COLSA  Inc,  and  SPARTA. 

The  Tiger  Team  determined  that  the  need  for  security  in  the  NTB  environment  is  dictat^ 
by  the  sensitivity  of  information  and  the  internal  and  external  threat  of  compromise  of  that 
information.  The  report  concluded  that  security  as  such  is  an  enabling  technology  which  provides 
a  wide  range  of  users  access  to  shared  communication  and  computing  resources  which  prewess 
information  at  multiple  levels  of  classification.  The  challenge  in  proviing  the  weded  security  is 
defined  by  the  environment  within  which  the  NTB  mission  must  be  performed.  The  key  elements 
of  Ac  mission  environment  include: 

a.  Geographically  dispersed  sites  wiA  many  different  AIS  platforms  and  numerous 
communications  requirements; 

b.  A  wide  range  of  users  firom  Ae  Government,  industry,  and  various  U.S.  Alties 
wiA  Averse  clearance  levels  and  Ascretionaiy  access  ctHitrol  requirements;  and 

c.  Data  wiA  a  wide  range  of  security  classification  levels,  multiple  categories  and 
several  COIs. 

The  report  included  system  level  requirements  and  alternative  archi^tures,  operationd 
concepts,  and  implementation  approaches  Aat  were  evaluated  bas^  upon  Aeir  project^  cost  Md 
responsiveness  to  the  system  level  requirements.  The  Tiger  Team 

estaWishment  of  MLS  nctwtwks  is  now  a  realistic  alternative  to  the  ccmtinued  prolrferation  of  single- 
level  networks.  Two  architectures  were  recommended,  architecture  1  and  architecture  3. 
Architecture  1  provides  direct  point-to-point  connectivity  between  sites,  where^  architectiro  3 
uses  packet  switching.  Architecture  1,  shown  in  Figure  1-1,  was  rerommended 
by  Ae  Tiger  Team  because  it  provides  high  commumcations  throughput  md  cm 
now  using  commercial  products  which  use  open  systems  protocols.  The  Tiger  Te^rep^ 
recommended  Aat  implementation  flexibility  would  be  maintained  by  sequencmg  a  proto^^ 
acquisition  phase  Aat  begins  at  Ae  LAN  level  Md  progresses  up  through  Ae  J^JJ^^Sdeway  tevcl 
to  Ac  backbone  network  level.  This  would  retain  Ae  option  to  mgrare  to  Architecture  3,  shown  m 
Figipe  1-2,  at  Ac  router/gateway  level  should  future  commercial  and  Government  developments 

merit  Ais  approach. 
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Figure  I- 1  Architecture  1 :  Direct  Connectivity  Figure  1-2  Architecture  3:  Packet  Switching 
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11. 


DEFINITIONS 


In  OTdcr  to  provide  the  mechanism  to  ensure  a  consistent  presentation  of  ideas  throughout 
this  document  the  following  terms  have  been  given  strict  definitions. 

(1)  Automated  Information  System  (AIS) 

A  set  of  computer  hardware,  software,  and  procedures  used  to  perform  a 
specified  function.  Examples  include  mainframes,  servers,  workstations, 
terminals,  printers,  and  sets  of  these  elements. 

(2)  Community  of  Interest  (COI) 

A  group  of  persons  and/or  systems  with  authorized  access  to  a  set  of 
information.  A  security  label  is  associated  (either  explicitly  or  implicitly)  with 
each  set  of  infcnmaticMi  which  identifies  the  hierarchical  classification  and  the  non- 
hierarchical  category(ies)  of  the  information  in  that  set.  The  hierarchical 
component  of  the  label  represents  the  classificaticm  level  of  the  data  and  indicates 
the  level  of  damage  resulting  from  the  acquisition  of  the  information  by 
unauthorized  p»sonnel.  The  non-hierarchical  component  of  the  label  provides  a 
mechanism  for  restricting  access  to  a  subset  of  those  persons  authorized  access  to 
all  information  at  the  given  hierarchical  security  level.  Persons  or  systems  that 
belong  to  a  COI  group  are  permitted  to  communicate  with  each  other,  but  are 
preclud^  firom  communicating  with  perswis  or  systems  that  do  not  belong  to  that 
COI  group.  A  clearance  or  access  authorization  is  associated  with  each  user  and 
group  of  users. 

(3)  National  Test  Bed  (NTB) 

The  AIS  equipment  and  its  environment  that  are  used  to  support  the  SDI 
Program  research  and  development  (R&D)  effort  These  assets  may  be  connected 
to  the  National  Test  Bed  Network. 

(4)  NTB  Network  (NTBN) 

The  communication  and  control  medium  that  permits  connection  between 
NTB  AIS  assets.  It  can  also  be  thought  of  as  being  bounded  by  the  last  electronic 
connection  of  any  NTB  AIS  Utat  can  oxnmunicate  with  any  otiter  NTB  AIS. 

(5)  NTBN  Node 

The  AIS  equipment  and  its  environment  at  a  particular  physical  location 
that  is  used  to  support  the  NTB  and  is  connected  to  the  NTBN.  (e.g.,  the  NTF, 
USA  SDC). 

(6)  Naticmal  Test  Facility  (NTF) 

The  AIS  equipment,  and  its  environment  at  Falcon  Air  Force  Base,  that  is 
used  to  support  the  NTB.  The  NTF  acts  as  the  hub  for  NTBN  communicatitMis. 
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III.  NEED  FOR  MLS  COMMUNICATIONS  AND  COMPUTING  ENVIRONMENT 


Within  the  National  Test  Bed,  there  is  a  need  to  provide  an  MLS  operational  environment 
such  that  Organizational  Conflict  of  Interest  (OCI)  needs  can  be  met  and  a  mix  of  U.S.  and  Allied 
users  with  a  wide  range  of  clearances  can  share  computing  resources  and  information  at  multiple 
levels  of  security  and  multiple  categories  while  maintaining  separation  in  accordance  with 
mandatory  and  discretionary  access  control  requirements.  Current  technology  will  not  fully 
support  "keyboard  to  database"  MLS  operations  due  to  the  lack  of  sufficiently  trusted  (beyond  Al) 
MLS  operating  systems,  applications,  and  database  management  systems. 

Levels  of  trust  range  from  D  (Minimal  Protection  System)  to  Al  (Verified  Design 
System)  where  A 1  is  the  highest  level  of  trust  currently  defined.  Levels  of  trust  beyond  Al  would 
be  necessary  to  provide  the  assurance  that  an  MLS  Network  with  uncleared  users  and  data 
sensitivities  up  to  Top  Secret  with  multiple  categories  did  not  present  significant  risks.  Until  levels 
of  trust  beyond  Al  are  defined  and  attainable,  the  minimum  user  clearance  must  be  higher  than 
uncleared  and/or  the  maximum  data  sensitivity  must  be  lower  than  Top  Secret  with  multiple 
categories  to  keep  the  risk  at  an  acceptable  level. 

First  generation  MLS  networks  are  however  achievable  using  Al  evaluated  components 
to  begin  the  evolutionary  process  of  developing  an  MLS  Network  that  will  be  capable  of  meeting 
all  NTB  user  needs  in  the  long  tena  As  addtional  trusted  components  become  available,  they  can 
be  integrated  into  the  MLS  Network  to  more  fully  satisfy  NTB  user  needs.  As  security 
components  with  levels  of  trust  beyond  Al  are  developed  and  MLS  operating  systems  and 
applications  are  developed  they  can  be  integrated  into  the  NTBN  and  NTBN  nodes  to  irovide  MLS 
access  to  NTB  resources  and  ^ta. 
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IV.  EVOLUTIONARY  APPROACH 

The  system  high  NTBN  and  dedicated  and  system  high  NTBN  nodes  which  are  cunently 
capable  of  transferring  and  processing  data  at  the  Secret/CW  level  with  all  users  cleared  to  the 
Secret/CW  level  using  dedicated  mode  AISs  shall  evolve  to  the  MLS  mode  network  capable  of 
transferring  and  processing  data  at  sensitivities  ranging  from  Unclassified  to  Top  Secret  with 
multiple  categories  while  supporting  both  cleared  and  uncleared  users  using  a  mix  of  dedicated, 
system  high,  and  MLS  mode  AISs.  This  evolution  will  be  accomplished  in  three  phases. 

Although  the  COI  separation  and  minimum  user  clearances  and  corresponding  required 
level  of  trust  goals  for  each  phase  are  established,  early  implementation  of  individual  security 
features  such  as  MLS  operating  systems  and  applications  will  occur  as  they  become  available  for 
the  various  AISs. 


A.  Near  Term 

In  the  first  phase  (near  term:  FY  92-93),  the  NTF  LAN  shall  be  upgraded  to  MLS 
mode  with  the  ability  to  support  users  with  a  minimum  clearance  of  Secret  communicating  and 
processing  data  with  sensitivities  up  to  Secret  with  multiple  categories  (PROPIN,  WNINTEL, 
N(X:ONTRACT,  CNWDI,  and  ORCON). 

The  first  phase  of  the  evolution  shall  be  accomplished  by  the  addition  of  MLS 
security  components  to  control  the  flow  of  data  to  and  from  individual  AISs  and  groups  of  AISs  at 
the  NTF.  NTF  AISs  (e.g.,  mainframes  and  groups  of  mainfimnes,  workstations  and  groups  of 
workstations)  shall  have  the  ability  to  support  users  operating  in  any  one  of  several  COIs.  The 
COI  supported  by  each  NTF  AIS  shall  be  independent  of  the  COI  supported  by  the  other  NTF 
AISs.  All  other  NTBN  nodes  shall  support  users  operating  in  the  same,  single,  COI.  NTF  AISs 
will  be  able  to  exchange  data  with  other  NTF  AISs  and  with  the  other  NTBN  nodes  in  accort^ce 
with  the  security  policy.  Since  all  nodes,  except  the  NTF,  will  be  supporting  users  tolerating  in  the 
same  single  COI,  there  is  no  need  to  control  the  exchange  of  data  between  NTBN  nodes  during 
this  phase.  Therefore,  in  the  near  term,  security  components  will  only  be  needed  at  the  NTF.  Iii 
the  near  term,  the  security  components  shall  provide  at  least  a  B2  level  of  trust  when  evaluated 
using  Appendix  A  and  C  of  the  TNI. 

During  this  phase,  the  feasibility,  utility,  ease  of  use,  and  performance 
characteristics  of  the  MLS  security  components  and  their  effect  on  operations  shall  be  evaluated 
through  prototyping,  to  provide  a  basis  for  refinement  of  the  near,  mid,  and  long  term 
requirements. 


B. 


MidTcnn 


In  the  second  phase  (mid  term:  FY93-95),  the  NTBN  shall  be  upgraded  such  that 
each  NTBN  node  can  simport  users  operating  in  a  COI  which  is  independent  of  the  COI  supported 
by  any  of  the  other  nodes.  The  MLS  mode  of  operation  wiU  be  extended  fitim  the  NIF  LANout 
to  the  point  where  each  NTBN  node  connects  to  the  NTBN.  In  this  phase,  the  NTBN  and  NTBN 
nodes  shall  have  the  capabUity  to  support  users  with  a  minimum  clcai^w  of  SeCTct  ^  to  ^ 
access  to  data  up  to  the  Top  Secret  level  with  multiple  categones  (PROPIN,  NOFORN,  REL, 
WNINTEL,  CNWDI,  ORCON,  and  NOCONTRACT).  In  the  mid  t^  the  secunty  cor^nents 
shall  provide  at  least  a  B3  level  of  oust  when  evaluated  using  Appendix  A  and  C  of  the  TNI. 

The  second  phase  shall  be  accomplished  by  the  addition  of  security  componente 
to  individually  control  the  flow  of  data  to  and  from  each  NTBN  node.  At  the  end  of  the  second 
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phase,  the  NTBN  will  op^te  in  the  MLS  mode  with  a  combination  of  dedicated,  system  high,  and 
MLS  mode  nodes  suppc^ng  users  operating  in  multiple  independent  COIs. 

c.  LonsTenn 

In  the  third  phase  (long  term:  FY96-99),  some  of  the  NTB  AISs,  such  as  the 
NTF  CRAY,  IBM,  and  VAX  mainframes  and  user  workstations,  shall  be  upgrade  to  MLS  mode 
using  MLS  operating  systems  and  applications  that  are  trusted  to  segregate  information  within  an 
AIS  based  upon  data  sensitivities.  This  will  allow  NTB  users  op^ting  in  differing  COIs  to  fully 
share  the  NTB  computing  resources.  In  the  long  term,  the  security  components  shall  provide  at 
least  an  A1  level  of  trust  when  evaluated  using  Appendix  A  and  C  of  the  TNI. 

In  this  phase,  the  security  components  will  control  the  access  of  both  cleared  and 
uncleared  users  to  data  with  sensitivities  up  to  Top  Secret  with  multiple  categories.  The 
recommended  level  of  trust  for  such  a  network  is  beyond  the  state  of  current  computer  security 
technology.  The  recommended  minimum  user  clearance  and  maximum  data  sensitivities  for  an  A 1 
level  of  trust  are  shown  in  Tables  VI-4  and  VI-5.  However,  the  Designated  Approving  Authority 
(DAA)  may  authorize  operation  with  lesser  user  clearances  and/or  greater  data  sensitivities.  In 
addition,  as  higher  levels  of  trust  become  achievable,  the  allowable  minimum  user  clearance  and/or 
maximum  data  sensitivity  can  be  revised. 

In  the  third  phase,  as  MLS  operating  systems,  database  management  systems, 
and  applications  become  available  for  the  NTB  AISs,  they  will  be  able  to  support  concurrent  use  of 
NTB  computing  resources  (e.g.,  servers,  workstations,  and  CRAY,  IBM,  and  VAX  mainframes) 
by  users  operating  in  different  COIs.  Users  will  be  able  to  share  computing  resources,  data  in 
databases,  and  names  cm  name  servers,  and  to  more  easily  exchange  electronic  mail. 

The  MLS  NTF  LAN,  NTBN,  and  AISs  will  serve  as  models  for  the  other  nodes 
supporting  the  SDI  mission.  The  network  security  architectures  and  security  components  used  on 
the  NTF  LAN  and  the  secure  operating  systems  and  applications  on  the  MLS  NTF  AISs  could  be 
replicated  throughout  the  NTBN  nc^es  to  increase  the  sharing  of  SDI  communication  and 
computing  resources.  The  selection  and  implementation  of  MLS  capabilities  at  each  of  the  nodes 
will  be  the  responsibility  of  the  managers  of  those  ncxles. 
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V.  REQUIREMENTS 

This  section  contains  the  functional,  performance,  and  security  requirements  for  the 
security  components  for  the  near,  mid,  and  long  terms 

A.  Requirements  Applicable  To  All  Phases 

1.  Functional  Requirements 
The  security  components  shall: 

(1)  Allow  the  transfer  of  information  between  AISs  only  if  the  transfer  does  not 
violate  the  security  policy  enforced  by  those  components. 

(2)  Allow  the  transfer  of  information  between  NTBN  nodes  only  if  the  transfer  does 
not  violate  the  security  policy  enforced  by  those  components. 

(3)  Provide  the  capability  to  establish  and  change  the  set  of  COIs  and  to  identify  the 
current  COI  supported  by  AISs  and  NTBN  nodes. 

(4)  Provide  the  capability  to  increase  or  decrease  the  number  of  AISs  at  a  node  and 
the  NTBN  nodes  connected  to  the  NTBN  without  requiring  a  complete 
reaccreditation. 

(5)  Provide  the  capability  for  single  level  AISs  to  support  users  operating  in  one  of 
seve^  COIs. 

(6)  Provide  centralized  network  security  management 

2.  Performance  Requirements 
The  security  components  shall: 

(1)  Not  increase  communications  error  rates  above  1  in  10^2  (To  Be  Resolv^  TBR)) 
for  data  transfers  between  AISs,  between  AISs  and  NTBN  nodes,  and  between 
NTBN  nodes. 

(2)  Not  reduce  communications  availability  between  AISs,  between  AISs  and  NTBN 
nodes,  and  between  NTBN  nodes  below  99.95  (TBR)  percent 

(3)  Not  degrade  communication  bandwidths  between  AISs,  between  AISs  and 
NTBN  nodes,  and  between  NTBN  nodes  by  more  than  5  (TBR)  percent 

3.  Security  Reouirements 
The  security  conqxwients  shall: 

(1)  Be  developed  and  maintained  in  a  "closed"  security  environment  as  defined  in 
CSC-STD-003-85. 
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(2)  Implement  RFC- 1038,  Draft  Revised  IP  Security  Option  (RIPSO). 

(3)  Provide  the  capability  for  AISs  and  NTBN  nodes  supporting  users  operating  in 

the  same  and  differing  COIs  to  use  the  same  communications  path. 

(4)  Meet  the  security  requirements  in  the  following  documents: 

a.  SDIO  Directive  5206,  Automated  Information  Systems  (AIS)  Security 
Program,  September  1991 

b.  SDIO  Guideline  5206-G,  Automated  Information  Systems  (AIS)  Security 
Guidelines,  September  1991 

c.  SDIO  Manual  5206-M,  Automated  Information  Systems  (AIS)  Security 
Manual,  September  1991 

d.  DOD  Directive  5200.28,  Security  Requirements  for  Automated 
InformaticMi  Systems,  March  21, 1988 

e.  DOD  5200.28-STD,  Department  of  Defense  Trusted  Computer  System 
Evaluation  Cdteria,  December  1985 

f.  CSC-STD-003-85,  Computer  Security  Requirements  —  Guidance  for 
Applying  the  Department  of  Defense  Trusted  Computer  System  Evaluation 
Criteria  in  Specific  Environments,  June  25, 1985 

g.  CSC-STD-004-85,  Technical  Rationale  Behind  CSC-STD-003-85: 
Computer  Security  Requirements  —  Guidance  for  Applying  the 
Department  of  Defense  Trusted  Computer  System  Evaluation  Qiteria  in 
Specific  Environments,  June  25, 1985 

h.  NCSC-TG-005  (Version  1),  Trusted  Network  Interpretation  of  the 
Trusted  Computer  System  Evaluation  Criteria,  July  31, 1987 

B.  Near  Term  Requirements 

The  security  components  shall  provide  the  capability  for  the  exchange  of  data  in 
multiple  COIs  among  NTF  AISs  and  between  AISs  and  NTBN  nodes  operating  in  the  same 

COL  In  this  phase,  the  NTF  LAN  will  transition  to  the  MLS  mode  of  operation.  While  the  NTF 
LAN  will  be  MLS  in  this  phase,  all  of  the  other  NTBN  nodes  will  remain  in  the  system  high  or 
dedicated  mode  and  support  users  operating  in  the  same  single  COI.  In  this  phase,  the  COI 
supported  by  all  NTBN  nodes  other  than  the  NIF  will  be  identical. 
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1.  Fiincrional  Requirements 
The  security  components  shall: 

(1)  Control  the  simultaneous  transfer  of  data  among  NTF  AISs  and  between  NTF 
AISs  and  the  other  NTBN  nodes  at  the  following  security  levels:  Unclassified, 
Unclassified  Sensitive,  Confidential,  and  Secret  with  or  without  the  following 
releasability  markings:  PROPIN,  WNINTEL,  NOCONTRACT,  ORCON,  and 
CNWDI. 

(2)  Provide  the  capability  to  obtain,  store,  display,  and  change  the  security 
parameters  necessary  to  control  the  transfer  of  information  among  NTF  AISs  and 
between  NTF  AISs  and  the  other  NTBN  nodes. 

(3)  Provide  the  capability  to  collect  and  display  data  and  control  information 
transferred  among  NTF  AISs  and  between  NTF  AISs  and  the  other  NTBN 
nodes. 

(4)  Provide  the  capability  to  suppon  users  operating  in  one  of  several  COIs  as  a  COI  • 
group  on  all  of  the  NTBN  nt^es. 

2.  Security  Requirements 
The  security  components  shall: 

(1)  Have  sufficient  level  of  trust  to  permit  the  minimum  required  user  clearance  to  be 
Secret 

(2)  As  a  minimum,  meet  the  class  B2  level  of  trust  requirements  defin^to  DOD 
5200.28,  DOD  Trusted  Computer  Security  Evaluation  Criteria  (TCSEC).  A1 
security  components  shall  be  used  if  available. 

(3)  As  a  minimum,  meet  the  class  B2  level  of  trust  requirements  defined  in  NCSC- 
TG-005,  Trusted  Network  Interpretation  (TNI)  of  the  TCSEC  when  evaluated  as 
described  in  Appendix  A  and  C  of  the  TNL 

c.  Mid  Term  Requirements 

The  security  components  shall  provide  the  capability  for  NTF  AISs,  NTF  AISs 
and  NTBN  nodes,  and  NTBN  nodes  to  simultaneously  exchange  data  in  several  COIs.  In  tms 
phase,  each  NTBN  node  will  have  the  capability  to  support  users  operating  in  a  COI  which  is 
independent  of  the  COI  of  any  other  NTBN  node  or  any  NTF  AIS. 

i;  Functional  Requirements 

The  security  compements  shall: 

(1)  Control  the  simultaneous  transfer  of  data  among  NTF  AISs,  ^ween  NTF  AISs 

and  other  NTBN  no^s,  and  between  NTBN  nodes  at  the  followmg  secunty 
levels:  Unclassified,  Unclassified  Sensitive,  Confidential,  Secret  and  Top  S^t 
with  or  without  the  following  releasability  markings:  NOFORN,  REL, 
WNINTEL,  CNWDI,  ORCON,  NOCONTRACT,  and  PROPIN. 
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(2)  Provide  the  capability  to  obtain,  store,  display,  and  change  the  security 
parameters  necessary  to  control  the  transfer  of  data  among  NTB  AISs,  between 
NTB  AISs  and  other  NTBN  nodes,  and  among  NTBN  nodes. 

(3)  Provide  the  capability  to  collect  and  display  data  and  control  information 
transferred  among  NTB  AISs,  between  NTB  AISs  and  other  NTBN  nodes,  and 
among  NTBN  nodes. 

(4)  Provide  the  capability  for  each  NTBN  node  to  support  users  operating  in  one  of 
several  COIs. 

(5)  Provide  the  c^ability  fm*  each  NTBN  node  to  support  users  operating  in  different 
COIs. 

2.  Security  Requirements 
The  security  components  shall: 

(1)  Have  sufficient  level  of  trust  to  permit  the  minimum  required  user  clearance  to  be 
Secret 

(2)  As  a  minimum,  meet  the  class  B3  level  of  trust  requirements  defined  in  DOD 
5200.28,  DOD  Trusted  Computer  Security  Evaluation  Criteria  (TCSEC).  A1 
security  con^nents  shall  be  used  if  available. 

(3)  As  a  minimum,  meet  the  class  B3  level  of  trust  requirements  defined  in  NCSC- 
TG-005,  Trust^  Network  Interpretation  (TNI)  of  the  TCSEC  when  evaluated  as 
described  in  Appendix  A  and  C  of  the  TNI. 

D.  Long  Tmn.Rcauigment5 

The  security  components  shall  provide  the  capability  for  users  operating  in 
multiple  COIs  to  share  NTB  computing  resources  and  databases  and  for  NTB  AISs,  NTB  AISs 
and  other  NTBN  nodes,  and  other  NTBN  nodes  to  exchange  data  in  multiple  COIs.  In  this  phase, 
some  AISs  will  transidon  to  MLS  mode.  This  will  enable  users  with  a  wide  range  of  clearances  to 
process,  store,  and  access  data  in  multiple  COIs,  simultaneously,  on  a  single  AIS. 

1.  Functional  Requirements 

The  security  corrqxments  shall: 

(1)  dbntrol  die  simultaneous  processing  and  transfer  of  data  at  the  following  security 
levels:  Unclassified,  Sensitive,  Confidential,  Secret,  and  Top  Secret  with  or 
without  any  or  all  of  the  following  releasability  markings:  NOFORN,  REL, 
CNWDI,  WNINTEL,  ORCON,  NOCONTRACT,  PROPIN,  SIOP,  and  SIOP* 
ESI. 

(2)  Provide  the  capability  to  obtain,  store,  display,  and  change  the  security 
parameters  necessary  to  control  the  transfer  of  data  among  NTB  AISs,  between 
NTB  AISs,  other  NTBN  nodes,  and  among  NTBN  nodes,  and  within  MLS 
AISs. 


11 


(3)  Provide  the  capability  to  collect  and  display  data  and  control  information 
transferred  among  NTB  AISs,  between  NTB  AISs  and  other  NTBN  nodes,  and 
among  NTBN  nodes,  and  within  MLS  AISs. 

(4)  Provide  the  capability  to  establish  and  change  the  set  of  COIs  and  the  current  COI 
that  users  of  shared  MLS  NTB  computing  resources  operate  in. 

(5)  Provide  the  capability  to  increase  and  decrease  the  number  of  MLS  NTB 
computing  resources  without  affecting  the  security  of  the  NTBN. 

(6)  Provide  the  capability  for  an  NTB  AIS  to  support  users  operating  in  several 
COIs,  simultaneously. 

2.  Sftciiritv  Requirements 

TTie  security  components  shall: 

(1)  Have  sufficient  level  of  trust  to  permit  the  ntinimum  required  user  clearance  to  be 
Uncleared. 

(2)  Provide  the  capability  for  NTB  MLS  AISs,  NTB  non-MLS  AISs,  and  NTBN 
nodes  operating  in  differing  COIs  to  use  the  same  communications  path. 

(3)  As  a  minimum,  meet  the  class  A1  level  of  trust  requirements  defined  in  DOD 
5200.28,  DOD  Trusted  Computer  Security  Evaluation  Criteria  (TCSEQ. 

(4)  As  a  minimum,  meet  the  class  A1  level  of  trust  requirements  defined  in  NCSC- 
TG-005,  Trusted  Network  Interpretation  (TNI)  of  the  TCSEC  when  evaluated  as 
describ^  in  Appendix  A  and  C  of  the  TNL 

(5)  Provide  the  capability  for  MLS  AISs  to  support  users  operating  in  multiple  COIs, 
concurrently. 


12 


VI.  SECURITY  ARCHITECTURE 


This  section  defines  the  inodes  of  operation,  risk  indexes,  "open"  versus  "closed"  environments, 
and  presents  the  near,  mid,  and  long  term  security  architectures  which  suppon  evolution  from  the 
existing  system  high  NTBN  and  dedicated  and  system  high  NTBN  nodes  to  the  MLS  mode 
network. 


A.  Modes  of  Operation 

AISs  may  be  operated  in  one  of  several  modes,  including:  dedicated,  system 
high,  multilevel,  controlled,  and  compartmented.  These  modes  are  defined  in  CSC-STD-(X)3-085 
as  follows: 

(1)  Dedicated 

A  dedicated  mode  system  is  specifically  and  exclusively  dedicated  to  and 
controlled  for  the  processing  of  one  particular  type  or  classification  of 
information,  either  for  full-time  operation  or  for  a  specified  period  of  time. 

(2)  System  High 

A  system  high  mode  system  is  only  trusted  to  provide  need-to-know 
protection  between  users.  In  this  mode,  the  entire  system,  to  include  all 
components  electrically  and/or  physically  connected,  must  operate  with  security 
measures  commensurate  with  the  highest  classification  and  sensitivity  of 
information  being  processed  and/or  stoi^.  All  system  users  in  this  enviroimient 
must  possess  clearances  and  au^orizations  for  all  information  contained  in  the 
system,  and  all  system  output  must  be  clearly  marked  with  the  highest 
classification  and  all  system  caveats,  until  the  information  has  been  reviewed 
manually  by  an  authorized  individual  to  ensure  appropriate  classifications  and 
caveats  have  been  affixed. 

(3)  Controlled 

A  controlled  mode  system  is  a  type  of  multilevel  mode  security  in  which  a 
more  limited  amount  of  trust  is  placed  in  the  hardware/software  of  the  system, 
with  resultant  restrictions  on  the  classification  levels  and  clearance  levels  that  may 
be  supported. 

(4)  Compartmented 

A  compartmented  mode  system  is  allowed  to  process  more  than  two  or 
more  types  of  compartmented  information  (information  requiring  a  special 
authorization)  or  any  one  type  of  compartmented  infortMtion  with  other  than 
mmpartment^  information.  In  this  mo^,  system  access  is  secured  to  at  least  the 
Top  Secret  level,  but  all  system  users  need  not  necessarily  be  formally  authoriz^ 
access  to  all  types  of  compartmented  information  being  processed  and/OT  stored  in 
the  system. 

(5)  Multilevd 

A  multilevel  mode  system  allows  two  or  more  classification  levels  of 
information  to  be  processed  simultaneously  within  the  same  system  when  users 
are  not  cleared  for  all  levels  of  information  present 

The  modes,  as  listed  above,  can  be  thought  of  as  being  hierarchical  in  Aat  each 
succeeding  mode  provides  a  superset  of  the  protections  provided  by  the  mode  before  it  in  the  list 
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Also,  it  is  generally  more  difficult,  and  expensive,  to  implement  each  succeeding  mode. 
Therefore,  the  "lowest"  mode  which  will  provide  the  required  protection  should  be  selected  unless 
there  is  some  reason  to  select  a  "higher"  inode. 

The  NTBN  will  transition  from  system  high  and  the  NTBN  nodes  will  transition  from 
dedicated  and  system  high  mode  to  MLS  mode  in  response  to  mission  requirements  as  shown  in 
Table  VI-1. 


Modes  of  Operation  in  Each  Phase 


Near  Term 

Mid  Term 

Long  Term 

MLS  Network 

MLS* 

MLS 

MLS 

NTBN 

System  High 

MLS 

MLS 

NTF LAN 

MLS 

MLS 

MLS 

Other  NTBN  Nodes 
(NTBN  nodes  other 
AantheNTF) 

Dedicated  and 

System  High  (All 
users  supported  in  a 
single  COI) 

Dedicated  and  System 
High  (Each  other 
NTON  node  has  the 
potential  to  supper 
users  operating  in  a 
COI  which  is 
different  fiom  the 

COI  supported  by 
any  other  node) 

Dedicated,  System 
High,  and  N^S 

NTB  AISs  at  the  NTF 

Dedicated  and 

System  High  (Some 
support  users 
operating  as  part  of  a 
COI  group  and  others 
(iterate  independently 
with  reflect  tt>  COI) 

Dedicated  and  System 
High  (Some  support 
users  operating  as 
part  of  a  COI  group 
and  others  operate 
independently  with 
resp^toCX>I) 

Dedicated,  System 
High,  and  N^S 

*  Note:  fa  the  near  term,  flie  MLS  Network  operates  in  the  MLS  mode  because  a  portion  of  the  system,  the  NTF  LAN, 

operates  in  the  MLS  mode.  The  NTBN  remains  in  the  system  high  mode  since  all  of  the  other  NTBN  nodes  continue  to 
operate  as  a  group  in  a  single  COI.  fa  the  mid  term,  the  NTBN  transitions  to  MLS  when  each  of  the  oAer  NTBN  nodes  can 
operate  in  a  different  COI. 


Table  VI-1 

In  the  near  term,  there  is  a  need  to  store  and  control  classified  and  unclassified  proprie^ 
data  belonging  to  multiple  contractors  and  classified  and  unclassified  SDI  data.  Data  ^  be  lawled 
using  proprietary  designators  that  indicate  which  contractor,  if  any,  is  the  "owner  of  that  Mta. 
The  existing  system  high  and  dedicated  mode  of  operation  can  not  segregate  ^ta  on  the  basis  of 
proprietary  labels,  or  any  other  security  designators.  Multilevel  mode  is  the  mu^um  mode  that 
will  segregate  users  based  upon  proprietary  designators.  Therefore,  dunng  the  near  term,  the 
operational  mode  of  the  MLS  Network  should  transition  from  system  high ,  prcwcssing  data  at  fte 
Secret/CW  level  to  MLS,  processing  data  at  the  Unclassified,  Unclassified  Sensitive,  Confidential, 
and  Secret  levels  with  multiple  categories. 
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In  the  near  term,  individual  NTBN  nodes  and  AISs,  and  groups  of  NTBN  nodes  and 
AISs,  will  be  operating  in  either  the  system  high,  dedicated,  or  MLS  mode.  As  shown  in  Table  VI- 
1,  in  the  near  term,  the  NTF  LAN  will  operate  in  the  MLS  mode.  All  nodes,  other  than  the  NTF, 
will  support  users  operating  only  in  the  same  single  COL  Some  of  the  NTF  AISs  will  support 
users  operating  as  a  COI  group  in  the  same  single  COI.  Others  will  support  users  operating  in  a 
COI  which  is  independent  of  the  COI  supported  by  other  NTF  AISs. 

It  is  essential  that  the  high  speed  "backside"  hyperchannel  links  between  the  NTF 
,  mainframes  (e.g.,  CRAYs,  IBMs,  VAXs)  be  made  switchable  to  allow  each  mainframe's  users  to 

operate  in  a  COI  which  is  independent  of  the  COI  supported  by  other  mainframes.  The  capability 
must  be  provided  to  logically  or  physically  remove  the  "backside"  connections  between 
mainframes  supporting  users  operating  in  different  COIs.  Since  there  are  no  evaluated  high  speed 
products  available  now  to  provide  logical  separation,  switches  will  need  to  be  added  to  physically 
1  segregate  the  mainframes  by  COI. 

In  the  mid  term,  the  other  NTBN  nodes  will  gain  the  capability  to  support  users  operating 
in  a  COI  which  is  independent  of  the  COI  supported  by  any  of  the  other  nodes.  This  will  allow 
individual  nodes  supporting  users  operating  in  different  COIs  to  share  the  NTBN,  simultaneously. 
Each  NTBN  node  (other  than  the  NTF  which  will  already  be  MLS)  will  continue  to  operate  in 
system  high  or  dedicated  mode. 

In  the  long  term,  some  of  the  AISs  will  transition  to  MLS  mode  through  the  addition  of 
MLS  operating  systems  and  applications.  Once  this  is  accomplished,  NTB  users  operating  in 
separate  COIs  will  gain  the  capability  to  share  NTB  computing  resources.  High  speed  secure 
gateways  should  available  during  this  phase  to  allow  replacement  of  the  "backside" 
hyperchannel  switches.  This  will  automate  the  transitions  between  various  groupings  of  AISs  into 
COIs. 


B.  Risk  Index 

Classified  data  must  be  protected  against  access  by  persons  not  having  sufficient 
clearance  and  need-to-know.  The  first  step  in  determining  the  recommended  minimum  level  of 
trust  of  an  AIS  required  to  protect  classing  data  is  the  determination  of  the  system's  risk  index. 
Risk  index  (RI)  is  defined  by  CSC-STD-003-85  as  the  dispari^  between  the  minimum  clearance  or 
authorization  of  system  users  (Rmm)  and  the  maximum  sensitivity  of  data  (Rmax)  processed  by  the 
system.  Table  VI-2  shows  the  calculated  risk  index  (RI  =  Rm«x  -  Rmin)  associated  with  a  system's 
minimum  user  clearance  and  maximum  data  sensitivity.  The  higher  the  risk  index,  the  higher  the 
recommended  level  of  trust  The  recommended  minimum  level  of  trust,  as  shown  in  Table  VI-3,  is 
also  dependent  upon  whether  a  system  is  developed  and  maintained  in  an  "open"  or  "closed" 
environment. 

For  the  near  term  ,  the  minimum  user  clearance  will  be  Secret  and  the  maximum 
data  sensitivity  will  be  Secret  with  multiple  categories  (Smc)-  Therefore,  the  risk  index  (Rmax  • 
Rmin )  as  shown  in  Table  VI-2  is  2  and  the  recommended  minimum  level  of  trust  for  a  "closed" 
environment  as  shown  in  Table  VI-3  is  B2.  In  the  mid  term,  the  minimum  user  clearance  will  be 
Secret  and  the  maximum  data  sensitivity  will  be  T(^  Secret  with  two  or  more  categories  (PROPIN, 
NOFORN,  WNINTEL,  CNWDI,  etc.)  Therefore,  the  risk  index  as  shown  in  Table  VI-2  is  4  and 
the  recommended  minimum  level  of  trust  for  a  "closed"  enviibnnnent  as  shown  in  Table  VI-3  is  B3. 
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Risk  Index 


u 

N 

Nmc 

Maximum  Data  Sensitivity  (Rmax*) 

C  Cmc  S  Sic  Smc 

TS 

TSic 

TS™ 

0 

1 
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4  5 

5 

6 

7 

Rmin** 
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0 

1 

2 

2 

3 

3 

4  5 

5 

6 

7 

1 

0 

0 

1 

1 

2 

2 

3  4 

4 

5 

6 

2 

0 

0 

(Vic 

0 

1 

1 

2  3 

3 

4 

5 

3 

0 

0 

(Vic 

0 

0/lc 

0 

1  2 

2 

3 

4 

4 

0 

0 

0/lc 

0 

0/lc 

0 

0/lc  1 

0 

2 

3 

5 

0 

0 

(Vic 

0 

0/lc 

0 

0/lc  0/lc 

0 

1 

2 

6 

0 

0 

(Vic 

0 

0/lc 

0 

0/lc  0/lc 

0 

0/lc 

1 

7 

0 

0 

(Vic 

0 

0/lc 

0 

0/lc  0/lc 

0 

0/lc 

0/lc 

Notes: 

«•  Rnu 

-  Maximum 

Dau  Sensitivity:  U 

s  Unclassified,  N  s 

Unclassified  but  Sensitive  ,  N^c 

s  Unclassified  but  Sensitive 

with  multiple  categories,  C  = 

Confidential,  C^c 

s  Confidential  with  mult^le  categories  (Note  that  Cic 

is  not  defined),  S  as 

Secret.  Sj*  =  Secret  with  one  categoiy.  S^^  »  Secret  with  multiple  categories,  TS  *  Top  Secret,  TS^  *  Top  Secret  with  one 
category,  TS^  =  Top  Secret  with  multiple  categories. 

b.  Rnria  •  User  Clearance  or  Authorization  0  *  Uncleared,  1  *  Not  cleared  but  authorized  access  to  sensitive  unclassified 
information,  2  *  Confidential.  3  «  Secret,  4  =  Top  Secret  with  a  Background  bivestigatkm.  5  =  Top  Secret  with  a  Special 
Background  Investigation.  6  *  Top  Secret  widt  Authorization  for  1  Compartment,  7  *  Top  Secret  with  Authorization  for 
Multiple  Compartments. 

c.  If  Rflrin  is  greater  than  or  equal  to  Rm-  and  *ere  are  categories  to  which  some  users  are  not  authorized  access,  then  die 
risk  index  is  1. 

Table  VI-2 


Recommended  Minimum  Level  of  Tnist^ 


Risk  Index 
0 

0 

1 

2 

3 

4 

5 

6 
7 


Security  Operating  Mode 
Dedicated 

System  High 

Limited  Access,  Controlled, 

Compaitmented,  Multilevel 

Limited  Access,  Controlled, 

Conputmented,  Multilevel 

Qmtrolled,  Con^iartmented,  Multilevel 

Multilevel 

Multilevel 

Multilevel 

Multilevel 


"Open" 

"aosed" 

Environment 

Environment 

No  Prescribed 

No  Prescribed 

Minimum 

Minimum 

C2 

C2 

B1 

B1 

B2 

B2 

B3 

B2 

Al 

B3 

* 

* 

Al 

* 

*  * 

(*  =  Beyond  Al) 


Table  VI-3 


2CSC-STD-003-85,  Table  3  on  page  12 
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Li  the  long  tenn,  the  minimum  user  clearance  will  be  "U"  and  the  maximum  data  sensitivity  will  be 
Top  Secret  with  two  or  more  categories.  Therefore,  the  risk  index  is  7  and  the  recommended 
minimum  level  of  trust  is  "beyond  Al".  At  the  A1  level  of  trust  for  a  "closed”  environment  if 
uncleared  users  are  supported,  the  maximum  data  sensitivity  level  recommended  would  be  Top 
Secret  with  no  categories.  Similarly,  to  support  a  maximum  data  sensitivity  of  Top  Secret  with 
multiple  categories  Ae  minimum  user  clearance  would  have  to  be  Confidential. 

C.  "Open"  vs.  "Closed"  Environments 

AISs  may  be  developed  and  maintained  in  either  "open"  or  "closed" 
environments.  Tables  VI-4  and  VI-5  show  the  relationship  among  the  type  of  environment,  the 
maximum  data  sensitivity  processed  by  a  system,  the  minimum  security  clearance  of  users  of  that 
system,  and  the  minimum  criteria  class  (level  of  trust)  required.  For  example,  in  an  "open" 
environment  system,  where  the  maximum  data  sensitivity  is  Secret  with  one  category  and  the 
minimum  clearance  held  by  any  user  is  Confidential,  an  Al  level  of  trust  as  defined  in  DOD 
5200.28  (The  "Orange"  book)  is  required.  However,  in  a  closed  environment,  a  B3  level  of  trust 
is  required.  Accreditation  may  be  achieved  with  lesser  levels  of  trust  than  those  recommended  if 
the  DAA  believes  there  is  a  rational  reason  to  accept  the  added  risk.  For  example,  the  risk  may  be 
mitigated  by  additional  security  constraints  provided  through  physical,  administrative,  and/or 
personnel  security. 

In  an  "open"  environment,  either  of  the  following  statements  is  true.  In  a 
"closed"  environment,  both  of  the  following  statements  are  true. 

(1)  Applications  developers  (including  maintainers)  have  sufficient  clearances  and 
authorizations  to  provide  an  acceptable  presumption  that  they  have  not  introduced  malicious  logic. 
Sufficient  clearance  is  defined  as  follows:  where  the  maximum  classification  of  the  data  to  be 
processed  is  Confidential  or  less,  developers  are  cleared  and  authorized  to  the  same  level  as  the 
most  sensitive  data;  where  the  maximum  classification  of  the  data  is  Secret  or  above,  developers 
have  at  least  a  Secret  clearance. 

(2)  Configuration  control  j^ovides  sufficient  assurance  that  applications  are  protected  against 
Ae  introduction  of  malicious  logic  prior  to  and  during  the  operation  of  applications. 

Since  scmie  of  the  software  and  virtually  all  of  the  hardware  will  not  be  developed 
by  sufficiently  cleared  personnel,  an  "open"  environment  will  result  unless  additional  security 
measures  are  implement^  Available  secure  interface  units  may  not  have  the  requisite  level  of  trust 
to  meet  the  minimum  user  clearance  and  maximum  data  sensitivity  requirements  in  an  "open" 
environment.  However,  these  security  interface  units  would  have  sufficient  trust  in  a  "closed" 
environment.  The  conversion  from  an  "open"  to  a  "closed"  environment  could  be  accomplished 
procedurally  by  requiring  that  all  hardware  and  software  developed  outside  the  environment  be 
reviewed  by  sufficiently  cleared  personnel  prior  to  its  use.  The  reviewers  must  be  cleared  to  at 
least  the  Secret  (TBR)  level.  Also,  once  it  has  been  reviewed  and  approved  for  u»,  it  may  not  be 
accessed  by  insufficiently  cleared  personnel  in  any  way  that  could  result  in  its  modification. 

D.  Near  Term 

AISs  may  be  connected  to  a  security  device  in  such  a  way  as  to  support  users 
operating  in  a  single  COI  or  in  multiple  COIs,  as  shown  in  Figure  VI-1.  Some  NTF  AISs  will 
always  support  users  operating  in  the  same  COI  as  other  NTF  AISs.  These  NTF  AIS  may  share  a 
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Level  of  Trust  Required  in  an  "Open"  Environment^ 


Minimum 
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C2 

MC 

Cl 

C2 

Maximum  Data  Sensitivity 
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B3 
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C2 
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C2 
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Table  VI-4 


Level  of  Trust  Required  in  a  "Closed"  Environment* 
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Table  VI-5 

Xhe  asterisk  (•)  indicates  that  computer  protection  for  environments  with  that  rak  index  are  consider^  to  be 
beyond  the  sute  of  the  current  technology.  Such  environments  must  augment  technical  protection  with  physical, 
Dersonnel.  and/or  adminisiiative  safeguards. 

j,  It  is  that  all  users  are  authorized  access  to  all  cattgories  present  system.  If  some  users  are  not 

authorized  for  all  categories,  then  a  class  B1  level  of  trust  or  higher  is  reQuired, 

c.  Where  there  are  more  than  two  categories,  at  least  a  B2  level  of  trust  is  required. 

d.  The  differences  between  the  tables  are  in  bold. 


3CSC-STD-004-85,  Table  5,  Page  13. 
4CSC-STD-004-85,  Table  7,  page  21. 
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LAN  connection  to  the  security  device.  Some  NTF  AISs  will  support  users  operating  in  different 
COIs  than  other  NTF  AISs.  Each  of  these  NTF  AISs  must  directly  connect  to  the  security  device. 

AIS  to  Security  Device  Connectivity 


AISs  Must  Operate  In  the  Same  AISs  May  Operate  In  Different 
Community  Of  Interest  Communities  Of  Interest 

Figure  VI- 1 

The  present  NTBN  architecnire  is  a  "bursted  star"  with  the  NTF  as  the  hub.  The 
architectures  shown  Mow  build  upon  that  structure  by  inserting  secure  interface  units  to  control 
the  flow  of  data  among  NTBN  nodes  and  NTF  AISs.  The  architectures  shown  below  are 
responsive  to  the  requirements  and  provide  a  framework  for  the  use  of  current  computer  security 
components  to  provide  an  MLS  mode  of  operation  at  the  NTF  LAN  level  in  the  near  term  wiA 
evolution  to  an  MLS  mode  of  operation  on  the  NTBN  and  at  the  NTBN  nodes  with  an  A1  level  of 
trust. 


As  shown  in  Figure  VI-2,  the  near  term  security  architecture  provides  the 
capability  for  NTF  AISs  connect^  by  an  MLS  LAN  to  exchange  data  with  other  hTTF  AISs  and 
for  NTF  AISs  to  exchange  data  with  the  other  NTBN  nodes  b^ed  upon  COI.  Secure  Interface 
Units  (SIU)  (e.g.,  Boeing  Secure  Network  Servers  (SNS))  and  the  Network  Control  Center 
(NCC)  (e.g.,  Boeing  Network  Manager  (NM))  control  the  transfer  of  data  among  NTF  AISs  and 
between  NTT  AISs  and  the  other  NTBN  nodes.  The  NTF  LAN  operates  in  the  MLS  mode  and 
suppons  multiple  COIs.  The  other  NTBN  nodes  support  users  operating  in  the  same  single  COI. 
The  SNSs  ensure  that  data  is  not  transferred  to  an  NTF  AIS  or  NTBN  node  unless  the  transfer  is 
in  accordance  with  the  security  policy. 

The  NCC  manages  the  security  tables  and  stores  the  audit  data  for  the  SIUs.  In 
this  phase,  the  NCC  only  needs  to  be  connect^  to  the  NTF  LAN  since  that  is  the  extent  of  the 
MLS  domain. 

E.  MkiTeim 

As  shown  in  Figure  VI-3,  the  mid  term  security  architecture  provides  the 
capability  for  each  of  the  NTBN  nodes  to  support  users  operating  in  different  COIs  and  for  the 
NTT  LAN  to  continue  to  support  users  operating  in  multiple  COIs.  In  the  mid  term  phase,  the 
NTT  AISs  and  each  of  the  other  NTBN  nodes  can  support  users  operating  in  a  COI  which  may  be 
different  than  the  COI  supported  by  other  AISs  and  nodes.  The  SIUs  ensure  that  data  is  not 
transferred  to  an  NTT  AIS  or  NTBN  node  unless  the  transfer  is  in  accordance  with  the  security 
policy. 
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Maximum  Data  Sensitivity:  Secret  /  Multiple  Categories 


The  network  control  center  manages  the  security  tables  and  stores  the  audit  data 
for  the  SIUs.  The  network  control  center  is  connected  to  the  NTBN  to  allow  it  to  control  the 
secure  interface  units  on  each  NTBN  node's  connection  to  the  NTBN. 

NTBN  nodes  are  currently  connected  to  the  NTF  by  a  combination  of  Type  1 
encryption  units  and  leased  T1  land  lines.  All  data  is  transmitted  to  the  NTF  regardless  of  its 
ultimate  destination.  If  secure  high  speed  (T1  or  T3)  packet  switch  interface  devices  and  data  padis 
are  available,  there  is  the  potential  for  the  transition  of  some  node  to  node  communications  to 
packet  switching  technology  during  the  mid  term.  This  would  reduce  the  amount  of  traffic 
transiting  the  NTF  and  make  the  network  less  susceptible  to  a  complete  failure  due  to  an  NTF 
outage. 


F.  Long  Term 

As  shown  in  Figure  VI-4,  the  long  term  security  architecture  provides  the 
capability  for  NTBN  nodes  to  support  users  operating  in  differing  COIs  to  share  the  computing 
resources  and  communication  media  and  for  n^es  supporting  users  operating  in  the  same  COI  to 
exchange  data. 

MLS  AISs  provide  the  capability  for  users  to  share  computing  resources.  Those 
MLS  AISs  that  implement  the  SNS  functions  will  not  require  an  SNS.  There  is  the  potential  for 
proliferation  of  security  features  (e.g.,  MLS  operating  systems  and  applications  at  the  NTF)  to 
other  NTBN  nodes. 
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Maximum  Data  Sensitivity:  Top  Secret  /  Multiple  Categories 
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Figure  VI-4  Long  Tenn  Securily  Arehilecl 
Al  Level  of  Assurance  as  a  Minimum 


Vn.  PRELIMINARY  IMPLEMENTATION  ARCHITECTURES 

Presently,  the  NTBN  is  operated  in  the  system  high  mode  at  the  Secret/CW  security 
level  All  data  is  treated  as  if  labeled  at  the  Secret/CW  level  and  all  users  have  at  least  a  Secret/CW 
security  clearance.  There  is  a  requirement  to  allow  users  operating  in  several  COIs  to  share  some 
of  the  computing  and  communication  resources  of  the  NTB. 

This  section  presents  preliminary  implementation  architectures  for  the  near,  mid,  and  long  terms  to 
satisfy  this  need.  While  the  figures  include  identification  of  specific  equipments  and  their 
interconnection,  there  may  be  other  equipment  suites  and  configurations  that  have  the  potential  of 
meeting  the  requirements.  The  purpose  of  this  section  is  to  illustrate  the  use  of  one  set  of  security 
interface  units  to  support  users  operating  in  several  COIs,  simultaneously.  The  actu^ 
configuration  implemented  will  be  determined  by  an  analysis  of  many  factors  such  as  the 
availability,  cost,  functionality,  accepted  level  of  trust  of  secure  interface  units;  the  minimum  user 
clearance,  acceptable  level  of  risk,  range  and  maximum  data  sensitivity;  and  the  development  and 
maintenance  environments. 

A.  Near  Term 

The  Tiger  Team  recommended  implementation  of  MLS  LANs  connect^  to  a 
communications  network  secured  by  link  encryption  devices.  The  evolution  of  this  architectiw 
will  begin  with  the  addition  of  secure  interface  units  and  switches  at  the  NTF  to  allow  the  NTF 
LAN  to  operate  in  the  MLS  mode.  NTF  AISs  supporting  users  operating  in  the  same  COI  will  be 
able  to  exchange  data.  An  MLS  device  installed  between  the  NTF  LAN  and  the  other  NTBN 
nodes  will  allow  the  other  NTBN  nodes  to  operate  in  a  single  COI  and  to  exchange  data  with  other 
NTBN  nodes  and  those  NTF  AISs  that  are  supporting  users  operating  in  the  same  COI. 

The  near  term  MLS  capability  can  be  achieved  using  physical  switches,  Boeing 
MLS  LAN  Secure  Network  Servers  (SNS),  and  a  Boeing  Network  Manager  (NM)  as  shown  in 
Figure  VII- 1.  The  SNSs  and  switches  are  shaded  in  the  figure.  The  switches  are  required  to 
control  the  hyperchannel  connectivity  between  the  IBM,  CRAY,  and  VAX  mainframes  to  allow 
them  to  support  users  operating  in  either  the  same  or  different  COIs  as  mission  requirements 
dictate.  While  the  figure  shows  the  capability  for  only  three  separate  COIs,  additional  switching 
could  provide  the  capability  for  more  COIs.  Also,  it  may  be  necessary  for  the  IBM  3090s  to 
support  users  operating  in  one  COI,  the  VAXs  to  support  users  operating  in  a  second  COI,  and  Ae 
CRAYs  to  support  users  operating  in  a  third  COL  Other  switching  configurations  could  provide 
the  capabOity  to  set  up  different  COIs  groupings  from  those  shown.  Procedures  will  be  required  to 
p^orm  "color  changes"  when  the  mainframes  transition  from  one  COI  to  another  to  ensure  that  no 
dara  remains  from  the  first  COL 

The  SNSs  can  be  trusted  to  ensure  separation  between  NTBN  nodes  and  AISs 
supporting  users  operating  in  different  COIs.  SNSs  will  provide  service  to  individual  AISs  and 
groups  of  AISs  on  a  LAN.  Each  AIS  with  an  individual  connection  to  an  SNS  rnay  operate  in  a 
separate  COI.  AISs  on  a  LAN  that  share  a  connection  to  an  SNS  must  operate  in  the  same  COI. 
In  addition,  the  SNS  has  the  capability  to  perform  the  one  way  guard  function. 

Each  SNS  can  suppon  up  to  seven  ethemet  cards  or  up  to  56  RS-232C  interfaces. 
The  arrangement  and  grouping  of  AISs  connected  to  SNSs  will  depend  upon  the  physical  location 
of  the  SNSs  and  the  AISs  they  service. 
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Figure  Vn-1  Near  Term:  1992  - 1993 
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The  Mandatory  Access  Control  and  Identification  and  Authentication  components  of  the 
Boeing  MLS  LAN  have  been  evaluated  at  the  A 1  level  of  trust.  The  NM  which  includes  the 
Discretionary  Access  Control  and  Auditing  components,  is  presently  being  evaluated  at  the  A 1 
level  by  NSA.  The  SNS  and  NM  are  being  upgraded  to  include  standard  interfaces  and  improve 
performance.  The  revised  SNS  and  NM  are  presently  in  the  NSA  developmental  evaluation  phase. 
Testing  is  schedule  for  September  through  December  1992  and  the  formal  evaluation  should  be 
complete  by  February  1993.  Therefore,  they  should  be  available  (in  evaluation)  in  the  near  term 
and  will  be  formally  evaluated  by  the  mid  term.  SNS  and  NM  capabilities  are  discussed  in 
Attachment  I. 


B.  Mid  Term 

The  mid  term  goals  can  be  achieved  by  installing  MLS  devices  as  interfaces 
between  each  of  the  NTBN  node  LANs  and  the  NTBN  as  shown  in  Figure  vn-2.  NTBN  nodes 
and  NTF  AISs  suppcaiing  users  operating  in  the  sante  COI  will  be  able  to  exchange  data. 

Although  each  NTBN  node  will  support  users  operating  in  a  single  COI  in  the 
mid  term,  all  NTBN  nodes  will  not  necessarily  support  users  operating  in  the  same  COI.  M  d^ 
exchanged  among  nt^es  is  presendy  processed  by  the  NX46(X)  at  the  NTF.  The  NX46(W  is  a  T1 
time  division  multiplex  device.  Therefore,  if  the  NX4600  (ot  other  similar  device)  remains  in  the 
communications  path,  data  of  multiple  COIs  may  be  present  in  the  NX46()0  at  any  given  time.  It  is 
possible  for  data  from  one  channel  to  be  sent  to  the  wrong  channel  due  to  an  NX4600  malfunction. 
Therefore,  Figure  VI-3  slwws  type  1  cncryptitm  devices  (NESs)  to  ensure  that  if  data  is  sent  to  the 
wrong  channel  by  the  NX46(X),  that  it  will  be  unintelligible  to  an  insrfficiendy  clear^ 

Type  1  encryption  is  required  because  an  untrusted  device  is  transferring  data  of  multiple  COIs  at 
the  same  time.  There  are  three  type  1  encryption  devices  (Motorola  Networl^c^tion  System 
(NES),  WANG  Trusted  Interface  Unit  (TIU),  and  XEROX  Encryption  Unit  (XEU))  that  could  be 
used. 

The  Motorola  NES  costs  about  $12,(X)0,  meets  SDNS  standards,  interfaces  with 
the  electronic  key  management  center,  does  not  encrypt  the  IP  header,  uses  an  open  architectiw 
that  reduces  evaluation  time  for  new  interface  cards,  and  uses  the  “FIREFLY”  encryption  algOTthm 
which  provides  electronic  key  management.  In  addition,  the  enhanced  version,  due  out  by  the 
fourth  quarter  of  1992  will  include  SNMP  and  electronic  update  of  configuration  tables  over  the 
network.  The  WANG  TIU  costs  about  $86(X),  has  64k  buffers  on  each  side,  does  not  enerwt^ 
IP  header,  and  responds  to  requests  for  status  via  ‘pings’.  The  XEROX  XEU  costs  atout  $6000 
and  encrypts  the  IP  header.  Encryption  of  the  IP  header  makes  the  packets  ms^ble  for  internet 
processing.  XEROX  has  an  additional  device  (a  combination  of  a  PC  ($1,500)  and  software 
($3  500)  that  can  be  added  to  the  communications  path  to  allow  use  of  the  IP  header  over  mtemm. 
Internetting  may,  or  may  not,  be  a  requirement  It  will  depend  upon  whether  internet  networks 
such  as  DISNET  are  used.  At  present  there  is  no  firm  requirement  for  mtemet  processing  of  data. 
Type  1  encryption  may  not  be  required  after  mid  term  if  the  NX4600  is  replaced  by  a  trusted  device 
or  ^  a  device  that  does  not  process  multiple  COIs  simultaneously  or  if  type  1  encryption  is  added 
to  the  SNS  at  a  reascMiable  cost 


The  Motorola  NES  is  the  recommended  solution  since  it  meets  SDNS  standards, 
interfaces  with  the  electronic  key  management  center,  does  not  encipt  the  IP  headw,  oi»n 

architecture  that  reduces  evaluation  time  for  new  interface  car(^  and  ums  the  FI^rLi 
encryption  algorithm  which  provides  electronic  key  management.  The  final  decision  yiU  depend 
upon  Ae  following  factors:  need  for  encryption,  requirement  fw  mternetting,  requirenMnt  fw 
SNMP  capability,  availability  of  SNS  with  encryption,  and  cost  This  ^ision  can  be  delayed 
until  addition^  ^ta  is  available  since  there  is  no  i»oblem  until  mid  term  (1993). 


26 


New  Nodes  |-|sNsV|nES|-|  Bridge  KG  94 

_NX4600  or 


c$  |- 

SAC 
LANL 
ASC  |-J 

SDIO  1“ 

SSD  |- 

NRL  hSNSHNES 


MCM"  i^iag 


MCM*  iCjyi 


EKElJiiisi 


t£UQ!l£l£l 


HiHjiasH 


-IBridge  ^E^^KG94^ 
H  Bridge  ^j^;2li:”i^TcG94T- 


-j  KG  94 
-i  KG  94  h 
-1  KG94h 
1^0  94}- 


H  KG94H 


"^w}- 


-[BSir}|^g^{TO3- 


KG94|- 


ESD  Bridge  KG94  t- 


SDC  UsNSljNESl4B5;n4e'2^rti  KG  94  h 


-I  KG  94  h 
H  KG94W 
■I  KG  94  I- 
4  KG94|- 


Bridge 
-j  Bridge  |iJ 
H  Bridge  I- 


NX4600I 
or 

palace- 
ment 


Bridge  ^ 
Bridge^ 

-j  Bridge  ]- 
Bridge  [■ 

-I  Bridge  UNES] 
•>\  Bridge 


SNSh— 1 


SNS 


1  sr 

is  1 

IBM 

3090 

CRAY 

Hyper 

Channel 

Hyper 

Channel 

Computer  Center 


SNS 


■MW 

MHIHM 

CRAY 

IBM 

3090 

VAX 

8810 

■■■■MM 

ngnsa 

IliSSil 

159 

fei!W!Wl| 

ISEJBi 

X 


VAX 

8800 

I 


Star 

Couplerl 


VAX 

8700 

Work 

stations 

Printers 


■PBHBmBBH 

1  SNS  1 

■■■■1 

mm 

■ 

I!! 

m 

s 

_ 

rotk 

dons 

DESC 


pn 

mm 

n! 

li 

LI 

^ofk 

tkms 

Special  Bogruns 


1  SNS  1 

■ 

■■HIM 

Work 

1 

File 

stations 

1 

Servers 

MODCom;^ 


SNS 


u 


Work 

stationa 


iP^ 

File 

«  Server! 


Hie 

Servers 


STS 


SNS 


Mil 

!!■ 

pi: 

pr 

pi 

1 

R 

^ofk 

linnc 

Hk 

Server 

Hie 

Server 

File 

Senrer 

MMliMl 

Gaming 


Figure  Vn-2  Mid  Term:  1993  - 1995 
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c.  Long  Term 


The  long  term  goals  can  be  achieved  by  installing  hardware  and/or  software  that 
results  in  MLS  AISs  as  shown  in  Figure  Vn-3.  The  switches  on  the  high  speed  inter-mainframe 
busses  will  be  replaced  by  high  spe^  MLS  gateways.  This  will  enable  additional  flexibility  and 
control  over  COI  groups.  The  NESs  will  no  longer  be  required  if  the  SNSs  have  type  1  encr^tion 
by  1996  or  if  there  are  no  untrusted  devices  (e.g.,  NX4600s)  processing  multiple  COIs. 

In  the  long  term,  the  users  operating  in  multiple  COIs  will  have  the  capabilipr  to 
share  the  computing  resources  of  the  MLS  Network  using  SNSs  and  MLS  hosts  and  workstations. 
MLS  hosts  and  workstations  will  provide  the  capability  for  users  to  operate  in  several  COIs 
simultaneously  and  for  those  users  to  share  databases  and  processors  since  MLS  hosts  and 
workstations  will  be  trusted  to  segregate  data  by  COI  on  a  single  platform.  Not  all  of  the  NTBN 
AISs  will  transition  to  MLS  mode.  Some  will  continue  to  operate  in  the  dedicated  or  system  high 
mode  because  MLS  operating  systems  and/or  applications  are  not  available  or  there  is  no  mission 
requirement  to  operate  in  the  MLS  mode. 
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ATTACHMENT  I 

Boeing  Secure  Network  Server  and  Network  Manager  Cabilities 


Attachment  I  -  Boeing  Secure  Network  Server  and  Network  Manager  Capabilities 

The  Boeing  Multilevel  Secure  Local  Area  Network  (MLS  LAN)  is  a  networic  component  providing 
MLS  communication  between  attached  devices.  The  MLS  LAN  is  composed  of  multiple  Secure 
Network  Servers  (SNSs)  connected  by  coaxial  cables  and  a  Network  Management  (NM) 
workstation.  The  SNS  is  a  network  access  device  with  embedded  upper-level  DOD  protocols, 
including  Internet  Protocol  (IP),  Transmission  Control  Protocol  (TCP),  TELNET,  and  User 
Datagram  Protocol  (UDP).  The  SNS  (configured  with  a  video  cable  plant)  also  supports  analog 
video  transfer  throu^  circuit  switching  capability. 

The  SNS  suppOTts  terminal  (RS-232C),  serial  host  (RS-232),  multiplexed  host  (IEEE  802.3  or  DR- 
1 1 W),  and  video  (NTSC)  subscriber  devices,  as  well  as  NM  and  Audit  Server  interfaces  (RS-232 
or  IEEE  802.3).  Terminals  are  attached  to  the  SNS's  terminal  device  interface  card  through  a 
standard  RS-232C  interface.  User  identification  and  authentication,  access  control,  and  auditing 
security  functions  are  performed  by  the  terminal  device  interface  card.  Hosts  are  attached  to  the 
MLS  LAN  through  either  serial  (RS-232C)  interface  cards  or  host  device  interface  cards.  The  host 
interface  card  supports  multiple  physical  host  interface  types  providing  multiplexed  services  to  tiie 
host. 

The  MLS  LAN  uses  a  distributed  network  management  approach,  with  a  centralized  NM 
workstation  providing  system-level  monitoring  and  control,  and  distributed  networic  management 
software  in  the  SNSs  providing  local  management  suppcni 

The  are  several  upgrades  in  progress  for  the  SNS  and  NM  wcH’kstation.  The  upgrades  will  be  in 
evaluation  at  the  A 1  level  by  1^3  (end  of  near  term)  and  therefore  the  SNS  and  NM  should  be 
usable  at  that  time.  The  evaluation  phase,  normally  18  months  long,  could  be  reduced  to  about  3 
months  by  use  of  the  NSA  Scientific  Research  Center. 

The  current  SNS  and  NM  have  some  limitations  which  would  affect  their  use.  However,  they  are 
being  upgraded  and  these  limitations  will  be  overcome  with  the  next  versions.  The  existing 
problems  and  solutions  are  as  follows: 

( 1 )  The  SNS  throughput  is  constrained  by  the  processing  speed  of  the  286  processor. 
The  upgraded  versions  of  the  SNS  and  NM  will  use  386  processors  instead  of  286  processors. 
The  throughput  and  performance  should  be  evaluated  in  the  near  term  tiuough  prototyping. 

(2)  The  SNS  throughput  is  constrained  by  the  SNS-to-NM  connection.  The  NM  is 
responsible  for  management  of  Discretionary  Access  Control  data.  All  audit  data  is  sent  to  the 
NM.  The  NM  connects  to  one  of  the  SNSs  using  either  an  RS-232C  or  ethemet  connection.  This 
data  path  constrains  SNS  throughput  since  DAC  information  is  required  by  the  SNS  and  many 
actions  must  be  audited  before  data  may  be  passed.  The  revised  NM  will  be  integrated  with  tm 
SNS.  As  a  result,  the  bandwidth  will  only  be  limited  to  the  bandwidth  of  the  SNS  data  bus.  This 
should  significantly  increase  SNS  throughput  The  throughput  and  performance  should  be 
evaluated  in  the  near  term  through  prototyping. 

(3)  Currently,  each  SNS  ethemet  port  can  only  interface  with  one  AIS.  These  ports 
can  not  be  used  to  process  data  to/from  a  LAN  with  multiple  AISs.  The  upgraded  SNSs  and  NM 
will  provide  the  capabiUty  to  allow  a  connection  between  an  SNS  and  a  LAN  which  has  multiple 
AlSs.  This  will  be  accomplished  by  the  addition  of  IP  routing  functionality  to  the  SNS  and 
upgrades  to  the  NM  to  handle  the  SNS  IP  changes.  This  will  remove  the  restriction  from  using 
LANs. 
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(4)  The  TCP/IP  interface  to  AISs  is  non-standard.  It  is  a  variation  of  the  World  Wide 
Military  Command  and  Control  (W^CCS)  host-to-front  end  protocol.  Either  an  AIS  to  front 
end  processor  or  new  AIS  TCP/IP  software  would  be  required  to  allow  an  AIS  to  interface  with 
the  SNS  as  currently  designed.  The  SNS  will  be  revised  to  use  the  standard  TCP/DP  interface. 
This  will  enable  any  AIS  with  a  standard  TCP/IP  interface  to  use  the  SNS.  Therefore,  the  NTF 
AISs  should  be  able  to  connect  to  the  SNS  without  modification. 

(5)  The  NS  A  evaluation  only  provides  A1  level  of  trust  for  Mandatory  Access 
Control  (MAC)  and  Identification  and  Authentication  (I).  The  NM,  which  performs  Audit  (A)  and 
Discretionary  Access  Control  (DAC),  is  presently  being  evaluated  by  NSA  at  *e  A1  level.  All 
four  elements  (MAC,  A,  I,  and  DAQ  are  required  for  accreditation  at  the  A1  level.  >JTien  the  NSA 
formal  evaluation  is  complete,  the  SNS  and  NM  will  provide  these  four  elements  at  the  A1  level  of 
trust.  Therefore,  accreditation  at  the  A1  level  of  trust  should  be  achievable  using  SNSs  and  the 
NM.’ 


(6)  The  SNSs  communicate  with  each  other  as  hosts  on  a  "class  A"  network  with  an 
unregistered  internet  address  of  “0.x.y.z”.  This  would  preclude  dieir  use  over  other  networks 
using  IP  routing.  The  upgraded  SNS  will  use  “globaUy  assigned  ethemet  addressing.  Therefore, 
since  the  upgraded  SNS  will  also  use  the  standard  TCP/IP  addressing,  internetting  will  be 
possible.  The  SNSs  do  not  use  the  IP  security  option  field  for  the  security  label.  The  upgraded 
SNS  will  be  use  the  IP  security  option  field  for  the  security  label.  Boeing  has  not  develop^  a 
secure  IP  router.  However,  this  functionality  will  be  added  to  the  upgraded  SNSs.  In  the  mid  or 
long  term,  the  direct  connections  between  the  other  NTBN  nodes  and  the  NTF  ^y  be  replaced  by 
DISNET  connectivity  if  links  with  sufficient  trust  and  bandwdth  are  available.  Correction  of  these 
problems  will  allow  the  use  of  SNSs  and  DISNET  connections. 

(7)  The  SNSs  (like  most  MLS  devices)  require  that  the  trunks  connecting  thern 
together  be  “protected”,  since  they  do  not  include  encryption.  Boeing  plans  to  add  type  1 
en^tion  to  the  SNSs  in  the  future.  This  will  probably  take  about  three  years.  Tj^  1  encry|gOT 
units,  such  as  the  NESs,  can  be  used  to  protect  the  SNS  trunks  in  the  intenm.  Since  the  NESs 
provide  centralized  key  management  and  other  features(e.g.,  internetting,  open  architecture),  they 
are  a  good  choice  until  the  SNSs  include  type  1  encryption. 
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ATTACHMENTn 
Security  Engineering  Process 


Attachment  II  -  Security  Engineering  Process 

In  order  to  achieve  the  security  goal,  all  aspects  of  security  (computer  security,  communications 
security,  physical  security,  and  procedural  security)  must  be  addressed. 

Computer  Security  (COMPUSEC)  will  ensure  that  MLS  requirements  (e.g.,  mandatory  access 
controls  (MAC),  discretionary  access  controls  (DAC),  identification  and  authentication  (I&A),  and 
auditing)  are  addressed.  Communications  Security  (COMSEC)  will  be  ensured  by  using 
encryption  devices  and  applying  state-of-the-art  transmission  error  checking/data  integrity 
approaches  to  security  and  integrity  of  data.  Physical  security  will  address  user  access  to 
equipment  and  facilities,  user  clearances,  and  TEMPEST  controls.  Procedural  security  will  ensure 
that  security  standards  and  procedures  within  the  facility  are  met. 

In  the  past,  the  development  approach  of  many  AISs  treated  the  security  functionality  and  system 
engineering  functionality  as  separate  entities.  Due  to  contractual  and  budget  pressures,  the  design 
and  development  emphasis  was  placed  on  system  engineering.  As  a  result,  security  engineering 
implementation  suffered.  This  approach  resulted  in  a  well  designed  and  developed  system  with  a 
very  weak  security  implementatitMi.  Many  systems  failed  accreditation  or  never  t^ame  operational 
due  to  the  lack  of  security  functionality. 

The  design  and  development  approach  for  the  evolution  of  the  NTBN  and  NTB  nodes  must 
integrate  security  engineering  and  system  engineering  from  the  beginning.  All  design  and 
development  efforts  will  incorporate  both  security  engineering  and  systems  engineering 
requirements  throughout  the  life-cycle  of  the  MLS  Network.  The  result  will  be  an  MLS  Network 
that  provides  the  capability  for  users  with  various  level  of  clearance  to  simultaneously  access  and 
process  data  at  multiple  classification  levels. 

A.  Life  Cycle  Phases 

Six  phases  of  the  system  life  cycle  have  been  identified.  The  first  phase  focuses 
on  system  requirements  analysis.  In  the  second  phase,  a  detailed  design  is  developed.  In  the  third 
phase,  hardware  development,  software  development  and  unit  level  testing  are  performed.  In  the 
fourth  phase,  the  Computer  Software  Component  (CSCs)  and  Configuration  Items  (CIs)  are 
integrated  and  tested.  The  system  will  be  installed  and  fielded  in  the  fifth  phase.  The  final  phase 
will  provide  ongoing  operations  and  support 

1-  System  Requirements  Analysis  Phase 

a.  Requirements  Definition 

During  the  requirements  definition  process,  the  security 
requirements  are  identified  and  analyzed,  the  Security  Policy  is  defined,  and  a  security  model  is 
developed  as  a  high  level  abstract  of  the  security  requirements.  Analysis  of  die  requirements  and 
development  of  the  security  policy  and  model  are  pc^ormed  in  order  to  produce  both  an  informal 
and  a  formal  security  policy  model. 

b.  Requirements  Analysis 

DOD  52()0.28-STD  and  the  NTB  requirements  are  the  key  drivers 
to  establishing  the  final  security  requirements  baseline  and  the  design  and  development  of  the  MLS 
Network.  The  security  requirements  identified  from  these  sources  have  been  allocated  into  six 
major  functional  areas:  Mandatcny  Access  Control  (MAC),  Discretionary  Access  Ctontrol  (DAC), 
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Individual  Identification  and  Authentication  (I«&A),  Audit,  Continuous  Protection  and  Assurance. 
These  six  functional  areas  are  the  drivers  for  the  development  of  the  security  architecture  and  the 

test  plan. 

The  System/Segment  Specification  (SSS),  the  Philosophy  of 
Protection,  and  the  Security  Policy  Model  are  developed  together  during  the  System  Requirement 
Analysis  phase.  The  Philosophy  of  Protection  is  mapped  to  the  SSS  to  ensure  that  the  overall 
security  requirements  are  identified  and  documented.  The  Security  Policy  Model  is  mapped  to  the 
SSS  to  ensure  software  design  requirements  and  constraints  are  identified. 

c.  Security  Policy  and  Model 

The  primary  source  for  the  Security  Policy  is  the  Philosophy  of 
Protection.  In  addition,  other  significant  sources  to  the  Security  Policy  are  SDI  520^M,  DOD 
5200.28-STD,  and  NCSC-TG-005.  The  Security  Policy  presente  a  mandatory  set  of  rules  that  are 
enforced  by  the  security  components  to  support  the  processing  of  sensitive  data  in  a  secure 
environment. 


d.  Sv>;fem  Specification 

The  System  Specification  defines  the  system  level  requirements. 
The  specifications  integrate  both  security  engineering  requirements  and  system  engineering 
requirements  derived  from  the  requirements  analysis  described  above.  These  documents  further 
ensure  that  the  security  engineering  and  system  engine^g  requirements  and  design  are  mtegra^ 
to  form  one  complete  system,  as  opposed  to  establishing  separate  specification  documents  which 
could  lead  to  separate  and  potentially  inconsistent  design,  development,  and  implementation 
results. 


2.  Design  Phase 

The  preliminary  design  phase  consists  of  defining  a  preliminary  design  for 
each  esa  and  HWCI.  Detailed  design  consists  of  allocating  requirements  to  Computer  Software 
Units  (CSU)  and  hardware  components  and  establishing  design  requirements  for  each  umt 

a.  Allocation  of  Pnlicv/Model  and  Requirements 


During  the  preliminary  design,  the  high  level  rcquirerrient 
allocations,  the  security  poUcy,  and  the  security  model  are  decomposed  further  to  begin  the  detailed 
system  design.  Design  phase  design  requirements  are  established  on  a  componem  level  which  is 
similar  to  the  goal  of  providing  an  abstract  design  of  the  functions  of  the 
fTCB)  In  the  detailed  design,  requiremente  are  analyzed  thoroughly  and  allocated  to  me  CSC!  and 
HWCI  level,  CSQs  are  broken  down  into  CSCs  and  CSUs,  interfaces  are  define^  and  exceptions 
and  error  messages  are  made.  The  detailed  security  design  wiU  he  incorporated  into  the  over^ 
system  design  as  stated  in  the  System  Specification.  Although  tiie  system  will  incorpOTate 
commercial  Wthe-shelf  (COTS)  Trusty  Computing  ?a“saCB)  that  have  ah^ 
evaluated  against  the  Trusted  Computer  System  Evaluation  Cntena  (TCSEC) 
review  of  all  COTS  TC3s  will  be  performed  to  ensure  that  all  reqmr^nts  are  met  by  me  COTS 
TCBs'  security  features.  The  Detailed  Top  Level  Specification  (DTLS),  the  F^al  Top  Level 
Specification  (FTLS),  and  the  Software  Design  Document  (SDD)  are  develop^  togethw  durmg 
boA  the  preliminary  and  detailed  design  phases.  The  detailed  design  ^hase  is  ^  om 
the  approach  of  two  separate  development  paths  for  secunty  engmeenng  and  system  engmeenng 
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often  cross.  Ensuring  continued  integration  of  security  and  system  engineering  increases 
assurance  that  a  well  designed  and  secure  MLS  Network  is  developed 

b.  Documentation 

During  the  design  phase,  the  following  documents  will  be 
produced:  System/Segment  Design  Document  (SSDD),  Software  Design  Document  (SDD), 
Interface  Design  Document  (IDD),  Interface  Control  Document  (ICD),  and  Security  Design 
documentation.  The  SSDD  identifies  the  security  requirements  and  their  allocation  to  HWCIs  and 
CSCIs.  The  SDD  describes  the  complete  design  of  each  CSCI  identified  in  the  SSDD.  The  IDD 
and  ICD  define  the  detailed  design  for  internal  and  external  interfaces.  The  security  design 
documentation  for  this  phase  consists  of  the  Philosophy  of  Protection,  Security  Policy  m^el,  and 
DTLS. 


3.  Development  Phase 

During  the  development  phase,  the  primary  activity  will  be  software 
coding  and  CSU  development  based  on  the  requirements  established  during  the  detailed  design 
phase. 


To  provide  the  requisite  levels  of  assurance  for  software,  the  development 
will  be  performed  in  a  "closed"  security  environment.  All  personnel  having  access  to  MLS 
Network  will  have  sufficient  clearance  to  access  the  network.  Configuration  control  will  be 
implemented  to  ensure  that  applications  are  protected  against  the  introduction  of  malicious  logic 
prior  to  and  during  the  operation  of  applications.  Several  assurance  requirements,  such  as 
extensive  functional  testing,  penetration  testing  and  coirespondence  mapping  between  the  security 
model  and  the  design  will  be  implemented,  ^e  of  the  primary  goals  during  the  development  of 
the  MLS  Network  will  be  to  ensure  that  when  the  final  code  is  developed,  it  can  be  trusted  to 
reliably  enforce  the  controls  and  protection  mechanisms  required  to  meet  DOD  and  SDI  security 
guidelines. 


4.  Imcsraiign  Phase 

The  integration  phase  will  occur  in  three  subphases.  In  the  first  subphase, 
the  Computer  System  Units  (CSUs)  of  each  Computer  System  Component  (CSC)  will  be 
integrated  to  form  the  CSCs.  At  this  stage,  Unit  Development  Folders  (UDFs)  will  be  developed 
to  document  all  requirements  allocated  to  the  CSC.  In  addition,  unit  level  testing  will  be 
performed.  All  paths  of  the  code  will  be  rigorously  tested  during  unit  level  testing.  In  addition,  a 
covert  channel  analysis  will  be  performed  on  the  design  documents  and  MLS  Network 
implementation. 


The  second  subphase  will  integrate  the  CSCs  to  form  Computer  System 
Configuration  Items  (CSCIs).  Formal  test  procedures  will  be  developed  and  a  Formal 
Qualification  Test  ^CJT)  for  each  CSCI  will  be  performed.  Security  testing  will  begin  during  the 
CSCI  testing  phase  and  continue  throughout  the  final  System  and  Integration  Testing  period. 

Once  all  of  the  CSCIs  have  been  formally  tested,  the  third  subphase  of 
System  Integration  and  Testing  will  begin.  Formal  system  level  test  procedures  will  be  developed 
and  Formal  System  Integration  and  Testing  will  be  performed.  The  System  Integration  and 
Testing  will  test  the  functionality  and  the  security  requirenwnts  that  were  not  tested  at  the  FQT 
level.  Upon  completion  of  the  System  Integration  and  Testing,  the  Software  Test  Report  (STR) 
will  be  written  to  document  both  the  formal  security  testing  and  system  engineering  testing.  The 


34 


required  security  documentation  (i.e.,  the  Trusted  Facility  Manual  (TFM),  the  Security  Features 
User’s  Guide,  and  the  Configuration  Management  Plan)  will  be  delivered  in  this  phase. 

5.  Installation  and  Fielding  Phase 

The  security  aspects  of  installing  the  MLS  Network  wiU  consist  primarily 
of  physical  security  controls.  Key  issues  to  be  addressed  in  this  phase  include  the  design  of 
physical  control  zones  and  protected  distribution  systems,  red/black  separation,  and  verification 
that  the  physical  installation  is  fully  compliant  with  applicable  DOD  and  SDI  standards  and  does 
not  invalidate  the  trusted  and  secure  environment. 

6.  Operations  and  Support  Phase 

Once  the  MLS  Network  has  been  installed,  the  System  Security  Officer 
(SSO)  will  be  required  to  maintain  site  security  controls.  For  example,  the  SSO  will  add  new 
users  and  establish  access  authorizations.  In  addition,  general  operations  support  will  be  provided 
to  maintain  the  integrity  of  the  network.  Activities  during  this  phase  will  include  training, 
upgrades,  and  configuration  management.  In  addition,  periodic  audit  trails  will  be  produced  and 
reviewed  and  periodic  security  tests  and  diagnostics  will  be  performed. 

B.  TCSEC  Development  Paradigm 

The  TCSEC  does  not  explicitly  describe  a  fnunewwk  foe  the  system  development 
process  but  does  implicitly  embody  certain  design  principles.  The  TCSEC  is  intended  as  an 
evaluation  criteria  oriented  towards  tiie  evaluation  of  Ae  design,  instead  of  Ae  process  used  in  Ae 
design.  However,  in  order  to  achieve  a  desi^  Aat  can  be  evaluated  at  Ae  B2  and  higher  levels  of 
Ae  TCSEC,  it  is  necessary  to  follow  an  implicit  design  paradigm  which  consists  of  developing  Ae 
following  design  documentation  and  ccxrespcmdence. 

1.  Philosophy  of  Protection 

Intended  to  capture  the  essential  security  requirements  (e.g.,  access 
control)  and  how  Aey  are  translated  into  Ae  TCB.  This  is  an  informal  document  which  is  used  to 
identify  Ae  specific  TCB  protection  mechanisms. 

2.  Security  Policy  Model 

Once  the  essential  security  requirements  and  corresponding  protection 
mechanisms  have  been  identified,  a  formal  model  of  Ac  security  policy  can  be  developed.  T^e 
formal  model  is  a  maAematically  precise  statement  of  Ae  security  policy  for  the  system  un^r 
development  Formal  models  such  as  Ac  Bell  and  La  Padula  Model  arc  often  stated  m  t^  of  an 
abstract  model  and  a  concrete  model.  TTic  abstract  model  captures  Ae  essential  security 
requirements  while  Ae  cwicretc  model  provides  an  abstract  set  of  rules  of  operation. 

3.  Descriptive  Top-Level  Snedfications  (DTLSh 

The  abstract  rules  of  operation  can  Acn  be  elaborated  into  a  high-level 
design  specification  in  Ac  form  of  a  DTLS.  The  TCSEC  defines  a  Top-Lwel  Spwification  as  "a 
non-procedural  description  of  system  behavior  at  Ae  most  abstract  level.  Typic^y,  a  fractional 
spca^cation  Aat  omits  aU  implementation  details."  The  DTLS  is  vmttcn  in  an  infonmd  language 
and  must  completely  and  accurately  specify  Ae  TCB  interface  in  terms  of  wceimons,  error 
messages,  and  effects.  The  DTLS  is  mtended  to  capture  the  user  visible  acuons  of  Ae  TCB. 
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4. 


Formal  Top-Level  Specifications  (FTLS) 


The  highest  level  of  assurance  defined  in  the  TCSEC,  A 1,  requires  that  an 
FTLS  be  developed.  The  FTLS  is  written  in  a  formal  specification  language  (e.g.,  GYPSY)  and 
must  be  proven  to  enforce  the  security  policy  as  described  by  the  formal  model.  Because  most 
common  formal  specification  languages  can  not  be  used  to  specify  temporal  properties  and  subtle 
hardware  characteristics,  the  FTLS  is  not  r^uired  to  provide  a  complete  description  of  the  TCB 
interface.  Instead,  the  FTLS  must  only  provide  an  accurate  description  of  the  TCB  interface.  Both 
the  FTLS  and  the  DTLS  are  required  in  order  to  fully  specify  the  system  under  development. 

5.  Security  Policy  Model  to  FTLS  Correspondence 

To  gain  assurance  that  the  design  will  enforce  the  Security  Policy,  the 
FTLS  is  shown,  through  a  combination  of  formal  and  informal  techniques,  to  be  consistent  with 
the  formal  model. 

6.  DTLS  and  FTLS  Correspondence  to  the  TCB 

Once  the  design  has  been  shown  to  be  consistent  with  the  security  policy  it 
is  necessary  to  establish  that  the  TCB  is  consistent  with  the  design.  This  is  done  informally  and 
requires  establishing  the  correspondence  between  both  the  DTLS  and  the  FTLS,  and  the  TCB. 

7.  Coven  Channel  Analysis  (CCA) 

Additional  assurance  of  the  MLS  Network’s  security  is  gained  through  a 
CCA.  A  covert  channel  is  defined  by  the  TCSEC  to  be  "any  communication  channel  that  can  be 
exploited  by  a  process  to  transfer  information  in  a  manner  that  violates  the  system's  security 
policy".  For  TCSEC  B-Level  evaluations,  the  CCA  is  informal  and  is  performed  on  the  design 
documents  and  MLS  Network  implementation.  At  the  Al-Lcvel,  formal  techniques  are  used  and 
the  CCA  is  usually  performed  on  the  FTLS.  The  continued  existence  of  identified  covert  channels 
must  be  justified. 


8.  Functional  Testing 

Functional  Testing  is  similar  to  that  required  by  DOD-STD-2167A  and  is 
aimed  at  demonstrating  that  the  specifications  have  been  met 

9.  Security  Testing 

Security  Testing,  sometimes  called  Penetration  Testing  is  intended  to 
show  that  not  only  does  the  system  do  what  it  is  intended  to  do,  but  that  it  does  nothing  else.  In 
particular.  Security  Testing  attempts  to,  "uncover  all  design  and  implementation  flaws  that  would 
permit  a  subject,  external  to  the  TCB  to  read,  change,  or  delew  data  normally  denied  under  the 
mandatory  or  dianctionary  security  policy  enforced  by  the  TCB".5 


5DOD  5200.28-STD 
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10.  Security  Specific  Documentation 


a.  Trusted  Facility  Manual  OPM! 

The  TFM  is  addressed  to  the  ADP  system  administrator  and 
presents  cautions  about  functions  and  priyileges  that  should  be  controlled  when  running  a  secure 
facility. 


b.  Security  Features  User’s  Guide 

Describes  the  protection  mechanisms  proyided  by  the  TCB  and 

presents  guidelines  on  their  use. 


c.  Configuration  Management  Plan 

Describes  the  configuration  management  procedures  used  for 
controlling  changes  to  the  security  comptments  and  the  MLS  Network  during  their  entire  life-cycle. 

d.  Trusted  Distribution  Plan 

Describes  the  procedures  (e.g.,  site  security  acceptance  plan)  used 
to  ensure  that  the  TCB  software,  firmware,  and  hardware  updates  distributed  to  a  site  are  identical 
to  the  master  copies. 
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ATTACHMENTm 


MLS  Network  Prototyping  Plan 


Attachment  HI  -  MLS  Networic  Prototyping  Plan 

I.  INTRODUCTION 

A.  ScQCfi 

This  document  presents  the  detailed  prototyping  plan  for  the  implementation  of  a 
Multilevel  Secure  (MLS)  Network  prototype.  The  prototype  effort  will  evaluate  security 
architectures  and  MLS  components  to  verify  Aat  the  SDI  mission  requirements  can  be  supported  in 
an  MLS  environment.  The  schedules,  estimated  resources,  and  prototyping  methodology  to  be 
used  in  the  development  of  an  initial  prototype  and  the  phased  enhancements  to  the  initial  prototype 
necess^  to  support  the  implementation  and  migration  from  the  near  term  to  the  long  term 
capability  are  provided. 

B.  Objectives 

The  objective  of  this  document  is  to  define  the  prototyping  effort.  It  identifies  the 

steps  to  be  performed  and  describes  the  procedures  to  be  followed.  TTie  plan  establishes  facility 
and  personnel  requirements  and  specifies  the  criteria  to  be  used  for  testing.  The  relationship 
between  the  prototyping  effort  and  operational  activities  is  described.  It  includes  the  process  of 
transitioning  evaluated  hardware,  software,  and  procedures  into  the  operational  environment 

II.  PROTOTYPING  METHODOLOGY 

A.  Proof  of  Concept 

Rapid  prototyping  techniques  will  be  used  to  perform  proof  of  concept  and 
product  evaluations  prior  to  implementation  of  the  near  term  MLS  NTF  LAN. 

The  prototyping  effort  will: 

(1)  Identify,  compare,  and  select  architectures,  security  components  and 

configurations  with  the  potential  of  enabling  transition  to  a  MLS  mode  of 

operation  with  the  recommended  levels  of  trust  in  the  near,  mid,  and  long  term. 

(2)  Determine  the  degree  to  which  the  functional,  performance,  and  security 
requirements  are  met  by  candidate  systems  which  enable  MLS  operation  in 
various  configurations; 

(3)  Determine  the  potential  effect  on  operations  caused  by  the  use  of  alternative 
candidate  security  components  which  enable  MLS  operation  in  various 
configuraticms; 

(4)  Develop  and  test  the  effectiveness  of  transition  strategies  designed  to  progress 
from  a  system  high  and  dedicated  mode  environment  to  an  MLS  mode 
environment; 

(5)  Devise  and  test  alternative  operational,  maintenance,  and  administrative 
procttlures  necessary  to  maintain  accreditation; 


(6) 


Confirm  the  effectiveness  of  the  recommended  architecture  and  security 
components  by  performing  pre-operational,  pre-certification  and  pre-accreditation 
trials  to  ensure  the  success  of  operational,  certification  and  accreditation  testing. 

B.  Evaluation  Criteria 

The  prototype  will  be  evaluated  against  the  functional,  performance,  and  security 
requirements  applicable  to  the  near,  mid,  and  long  term  implementation  phases  as  defined  in 
Section  V  of  the  Guidance  and  Requirements  Document. 

C.  Transition  to  Operational  Mode 

Prototype  products  and  procedures  that  have  successfully  completed  evaluation 
and  verification  will  be  us^  in  the  implementation  of  the  operational  MLS  Network. 

III.  SCHEDULE 

A.  Initial  Prototvtx? 

In  order  to  complete  the  implementaticm  of  the  near  term  capabilities  during  FY93, 
the  initial  prototype  must  be  started  NLT  (To  Be  Determined  (TBD))  and  completed  within  TBD 
months. 


Based  on  the  current  availability  of  existing  MLS  security  components  it  is 
expected  that  mid  term  capabilities  will  be  implemented  almost  concurrently  with  the  development 
and  fielding  of  the  near  term  MLS  NTF  LAN.  Therefore  the  initial  protot^  should  also  be  used 
to  ensure  that  aU  mid  term  requirements  will  also  be  met 

The  initial  prototype  effort  will  consist  of  the  following  steps: 

(1)  Select  one,  or  more,  candidate  security  components  and  architectures  whose 
characteristics  indicate  that  they  have  a  reasonable  potential  of  satisfying  the  near 
and  mid  term  requirements  and  being  usable  in  the  long  term  timeframes.  The 
selection  will  be  based  upon  an  analysis  of  the  characteristics  (functional, 
performance,  and  security  features)  of  security  components  and  architectures 
identified  in  the  Guidance  and  Requirements  Document  with  the  potential  to 
transition  the  NTF  LAN,  NTBN,  and  existing  and  planned  AISs  (hosts  and 
workstations)  to  the  MLS  mode  of  (^>eiation. 

(2)  Prepare  a  plan  and  procedures  for  the  acquisititxi  of  the  selected  candidate  security 
compcments  and  their  installation  in  the  prototype  environment  using  the  selected 
architecture. 

(3)  Acquire  sufficient  quantities  of  the  selected  candidate  security  c(xnp<x)ents. 

(4)  Tngtall  and  instrument  (if  necessary)  the  selected  candidate  security  ccanponents. 

(5)  Devise  and  perform  tests  and/or  develc^  and  run  siinulations  to  ^termine  to  what 
extent  the  candidate  security  components  and  architectures  satisfy  the  near,  mid 
and  long  tenn  requirements. 
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(6)  Evaluate  the  results  of  the  tests/simulations  using  the  near  term  requirements  as  a 
standard  to  confirm  that  the  selected  security  components  and  architectures 
support  the  SDI  mission  in  an  MLS  environment  in  the  near  term, 

(7)  Evaluate  the  results  of  the  tests/simulations  using  the  mid  term  requirements  as  a 
standard  to  confirm  that  the  near  term  solutions  can  be  transitioned  to  the  mid  term 
environment. 

(8)  Evaluate  the  results  of  the  tests/simulations  using  the  long  term  requirements  as  a 
standard  to  confirm  that  the  near  and  mid  term  architectures  and  security 
components  will  support  evolution  to  the  long  term  architectures  using  the 
selected  security  components. 

(9)  Determine  the  effect  of  early  (in  near  term)  implementation  of  mid  term 
requirements  (i.e.,  MLS  NTBN). 

(10)  Provide  a  recommendation  as  to  the  'most  qualified*  security  components  and 
architectures  and  the  recommended  schedule  for  their  implementation. 

(11)  Develop  operational,  maintenance,  administrative,  and  security  procedures, 

(12)  Create  a  plan  and  procedures  for  certiHcation  and  accreditation  at  the 
recommended  level  of  trust 

(13)  Perform  pre-certification  and  pre-accreditation  testing  using  the  prototype 
configuration. 

(14)  Support  certificadon  and  accreditation  testing. 

(15)  Create  a  plan  and  procedures  for  integration  of  the  selected  security  components 
into  the  operational  system. 

(16)  Support  the  integration  of  the  selected  security  components  into  the  operational 
system. 

B.  Phased  Enhancements 

Current  technology  will  not  fully  support  "keyboard  to  database”  MLS  operations  due  to 
the  lack  of  sufficiently  trusted  (beyond  Al)  MLS  operating  systems,  applications,  and  database 
management  systems  for  the  NTB  mainframes  and  workstations.  During  the  mid  and  long  terms, 
the  ei^anced  prototype  will  be  used  as  follows: 

(1)  Evaluate  new  and  emerging  MLS  products  to  determine  the  feasibility  of  their 
incorporation  into  the  nCs  Network. 

(2)  Develop  operational,  maintenance,  administrative,  and  securiQr  procedures. 

(3)  Perform  pre-certification  and  pre-accreditation  testing. 

(4)  Support  integratitMi  of  new  and  emerging  MLS  products  into  the  MLS  Network. 
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IV.  RESOURCES  REQUIRED 


A.  Manpower 

Initial  prototype  by  Fiscal  Year  -  TBD 
Phased  enhancements  by  Fiscal  Year  -  TBD 

B.  Equipment/Facilities 

MLS  Hardware  and  Software  components 

Use  of  NTBN  and  NTB  assets  for  conduct  of  tests  and  evaluations 

Facility  for  prototype  staging  and  evaluation 

C.  Estimated  Costs 

Initial  Prototype  •  TBD 
Phased  Enhancements  -  TBD 


V.  SUMMARY 

Implementation  of  this  plan  and  commitment  of  the  required  resources  is  required  as  an 
initial  step  to  ensure  a  successful  migration  path  for  the  NTBN  and  NTBN  Nodes  as  they  transitiem 
from  the  current  system  high/dedicated  mode  of  operations  to  a  fully  accredited  MLS  Network  that 
supports  the  achievement  of  all  SDI  mission  objectives  and  requirements. 
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1.0  INTRODUCTION 

The  National  Test  Bed  (NTB)  Security  Strategy  Working  Group  (NSSWG)  provides 
this  paper  for  the  general  use  of  the  NTB  community.  It  is  meant  to  be  a  living  document, 
and  as  such,  will  be  updated  when  deemed  necessary  by  the  NSSWG.  The  current 
NSSWG  members  are:  the  NTB  Joint  Program  Office  (NTB/JPO);  the  NTB  Integrating 
Contractor  (NTBIC,  the  Martin  Marietta  Corporation);  Beta  Analytical,  Inc.  (BAI);  the 
MITRE  Corporation;  the  National  Security  Agency  (NS  A);  SPARTA,  Inc.;  and  the 
Strategic  Defense  Initiative  (SDI)  Organization  (SDIO). 


l.I  BACKGROUND 

The  NTB  is  a  set  of  distributed,  national  level  assets  that  suppon  studies,  analyses, 
simulations,  gaming  exercises,  and  other  scientific  activities.  Its  primary  job  now  is  to 
facilitate  the  Government's  decision  making  process  about  developing  and  deploying  the 
Strategic  Defense  System’s  (SDS)  elements,  as  pan  of  the  Scrate^c  Defense  Initiative 
(SDI)  Organization’s  (SDIO)  mission.  The  purpose  of  the  NTB  is  to  provide  a 
comprehensive  capability  to  compare,  analyze,  evaluate  and  test  alternative  architectures 
and  key  technologies  for  a  strategic  defense.  Included  is  the  ability  to  examine  technologies 
in  system  framework  defined  by  these  SDS  architectures.  The  definition  and  acquisition  of 
this  capability  has  been  centralized  in  order  to  ensure  that  a  single  integrated  capability 
dedicated  to  the  SDI  is  available  to  the  entire  SDI  community  for  addressing  the  many 
critical  issues  necessary  to  support  informed  decisions  on  the  future  development  and 
deployment  of  a  strategic  defense. 

The  NTB  Network  (NTBN)  can  be  thought  of  as  a  distributed  network  of 
heterogeneous  systems  that  suppon  the  NTB  mission.  As  Pan  of  that  mission,  the  NTBN 
must  provide  an  environment  that,  while  providing  the  requisite  security,  allows  user 
interaction  to  the  fullest  extent  possible  to  nunure  the  kind  of  "laboratory  setting"  that 
assists  in  the  research  process.  This  laboratory  setting  can  be  aided  by  properly  done 
security. 

Each  member  of  the  NSSWG  has  at  one  time  or  another  proposed  a  path  that,  if  taken, 
would  provide  the  NTB  with  added  security.  Each  has  been  somewhat  successful  in  some 
areas,  but  it  became  obvious  that  a  consolidated  effon,  following  a  single  security  vision, 
was  needed.  It  was  for  this  reason  that  the  Director,  Information  Systems  (SDIO/POI) 
called  together  the  coalition,  whose  member  organizations  are  identified  above,  caused  it  to 
be  chaired  by  the  Assistant  Director  for  Technical  Services  (SDIO/POIT)  and  gave  it  the 
mission  of  providing  the  future  vision  of  security  for  the  NTB.  Meetings  were  held  in 
December  1990  and  January  1991  to  provide  a  basis  for  the  needed  consensuses  and  to 
elicit  ideas.  This  repon  is  based  on  that  effon.  Additional  meetings  will  be  held  in  the 
future  to  further  this  aaivity.  This  report  will  be  updated  as  needecL 

In  recognition  of  these  missions,  efforts,  and  the  pan  that  security  must  play  in  the 
proper  operation  of  NTB  assets,  a  guiding  policy  statement,  for  the  NSSWG,  is  now 
given:  The  NTB  shall  incorporate  security  as  an  enabling  technology  to  provide  high 
assurance  of  information  confidentiality  and  integrity  in  concen  with  dynamic  resource 
utilization  by  a  diverse  community  of  users. 


1.2  SCOPE 

This  document  addresses  the  development  of  a  National  Test  Bed  Network  Security 
Architecture.  The  depth  of  development  is  bound  by  the  security  perspective.  Although 
operational  and  user  communiries  were  represented  on  the  NSSWG,  the  primary  focus  was 
security.  This  provided  a  unique  perspective  to  develop  a  robust  security  model.  The 
model  enables  the  NTBN  to  flexibly  reconfigure,  meeting  user  requirements  in  a  secure 
manner. 

This  document  is  not  meant  to  be  an  in  depth  analysis  of  the  security  needs  of  the 
NTBN  nor  to  fully  explore  dl  the  options  available  to  address  those  needs.  It  is  rather  to 
identify  a  method  for  establishing  possible  solutions  to  the  perceived  need  for  additional 
security,  in  context  of  the  NTB  mission  as  it  is  understood  currently.  Example  solutions 
are  included  to  stimulate  comm  unity- wide  discussion. 


1.3  REQUIREMENTS 

The  requirements  identified  here  are  with  respect  to  the  generalized  system  and  are 
given  as  a  vehicle  for  discussing  the  security  requirements  of  the  system. 

1.3.1  User  Requirements 

The  NTB  must  provide  users  with  the  computer  processing  power  that  will  enable 
them  to  simulate  and  validate  SDS  architectures  and  designs.  Tliis  includes 
supercomputing,  workstation  graphics,  and  high  speed  connectivity  among  NTB  nodes  in 
order  for  users  to  accomplish  their  tasks.  It  is  also  includes  large  amounts  of  (classified) 
multilevel  information  to  process;  different  supporting  contractors;  and  participation,  in 
suppon  of  Spi,  by  Allied  scientist.  Users  with  large  system  simulations  will  require  great 
amounts  of  time  on  supercomputing  systems  and  must  have  the  ability  to  move  the 
resulting  data  to  various  graphic  workstations  (potentially  at  various,  geographically 
separated  sites)  in  almost  real-time.  The  roles  of  different  nodes  of  the  NTB  will  not  be 
addressed  here  now.  Instead,  the  focus  will  be  upon  fully  shared  resources,  the  NTF  and 
NTBN.  Generally  speaking,  in  suppon  of  the  above  requirements, the  NTF  must  fulfill 
three  major  areas  of  functional  requirements.  It  must  act  as: 

1)  Data  Center, 

2)  Test  Bed,  and 

3)  Information  Resource. 

It  must  fulfill  the  three  major  areas  in  light  of:  1)  multiple  levels  of  classified  Hara;  2) 
multiple  supporting  contractors;  and  3)  panicipation  of  Allied  scientific  representation. 

Again  generally  speaking,  the  NTBN  must  act  as  the  high-speed,  wide- bandwidth 
communications  media  that  would  provide  the  "near  real-time"  site  interactions.  Even  with 
just  these  high  level  descriptive  requirements,  we  have  set  the  stage  for  system  level 
security  requirements. 

1.3.2  System  Functionality 

In  suppon  of  the  SDI  mission,  the  NTB  goals,  primarily  focused  at  the  NTF,  arc: 

1)  To  provide  a  common  test  environment  for  the  design  of  SDS. 


2)  To  simulate  and  validate  SDS  elements  and  overall  system  concepts. 

3)  To  suppon  the  planning  and  conduction  of  system  element  and  overall  system 
studies  and  analyses  that  are  excursions  to  the  baseline  SDS  concept. 

4)  To  provide  suppon  to  USSPACECOM  for  Concepts  of  Operations  (CONOPS) 
and  operational  training. 

5)  To  serve  as  a  coordination  center  for  SDI  field  experiments  involving  multiple 
ranges  and  assets. 

6)  To  establish  and  maintain  a  state-of-the-an  simulation  and  analysis  capability 
including  connectivity  to  other  nodes  of  the  NTB  and  SDIO  Data  Centers. 

7)  To  provide  a  data  repository  for  all  SDIO  approved  software  models,  system 
level  experiments,  and  simulation  data. 

8)  To  maintain  configuration  control  of  all  SDS  models  and  SDS  operational 
software. 

9)  To  collect,  store,  and  manage  the  configuration  of  standard  SDI  threat  data  and 
generate  threat  tapes  for  dissemination  to  authorized  users. 


1.3.3  Security  Requirements 

The  NTB  must  prevent  disclosure  of  classified  data  to  uncleared  users  and  ensure  that 
unauthorized  users  do  not  access  the  system.  (This  is  a  requirement  on  all  entities  that 
handle  or  process  classified  information,  not  just  the  NTB.)  To  restrict  classified  data  to 
only  those  users  who  are  appropriately  cleared,  the  NTB  must  provide  separate  processing 
environments  for  each  level  of  classified  information  being  processed.  Currently,  the  NTB 
can  suppon  data  processing  at  the  unclassified.  Secret  Collateral,  and  Top  Secret  levels. 
This  is  in  totally  separate  environments,  with  no  electronic  means  for  the  transference  of 
data,  nor  the  capability  to  process  at  any  adjacent  levels  (i.e..  Secret-only  processing).  To 
meet  the  projected  user  requirements  and  to  enhance  the  current  capabilities,  the  NTB,  and 
in  particular  the  NTF  and  the  NTBN  should  suppon  a  Multilevel  Secure  (MLS)  mode  of 
operation  (see  Section  "Multilevel  Security").  Also,  as  more  network  connections  are  made 
and  the  number  of  users  of  the  NTB  increases,  the  potential  for  loss  from  fraudulent  use 
increases.  To  prevent  this,  the  NTB  must  ensure  that  all  users  that  access  the  system  are 
authorized  to  do  so.  Positive  user  identification  and  authentication  is  required.  Therefore, 
the  NTB  should  investigate  other  authentication  techniques  to  augment  the  current 
password  mechanisms  (see  Section  "I&A  Beyond  Passwords"). 


2.0 


DEFINITIONS  &  CONCEPTS 


2.1  WORKING  DEFINITIONS 

To  provide  the  NSSWG  a  good  foundation,  and  to  encourage  the  consistent 
presentation  of  ideas,  certain  generally  used  terms  were  given  strict  definitions.  These 
definitions  have  help  the  group  focus  on  the  problems  at  hand  father  than  focusing  on  a 
particular  person's  definition  of  a  term).  The  definitions  have  also  served  as  a  vehicle  by 
which  some  underlying  concerns  could  be  more  readily  surfaced  and  dealt  with.  They  are 
present  here  for  those  same  purposes.  Remember  that  the  focus  in  on  Automated 
Information  Systems  (AIS). 

1)  National  Test  Best  (NTB) 

The  AIS  equipment,  and  its  environment,  that  is  used  to  suppon  the  SDIO 
research  and  development  (R&D)  effort.  The  assets  may  be  connected  to 
the  National  Test  Bed  Network  (which  is  pan  of  the  NTB). 

2)  NTB  Network  (NTBN) 

The  communication  and  control  media  that  permits  connection  between 
NTB  AIS  assets.  (It  Can  also  be  thought  of  as  being  bounded  by  the  last 
electronic  connection  of  any  NTB  AIS  that  can  communicate  with  other 
NTB  AISs. 

3)  NTBN  Node 

The  AIS  equipment,  and  its  environment,  at  a  particular  physical  location 
that  is  used  to  suppon  the  NTB  and  is  connected  to  the  NTBN.  (E.g ,  the 
NTF  or  SDC).  ^ 

4)  National  Test  Facility  (NTF) 

The  AIS  equipment,  and  its  environment,  at  Falcon  Air  Force  Base,  that  is 
used  to  suppon  the  NTB.  (E.g,,  Computer  Room  1  and  Directed  Energy 
Suppon  Center.)  They  are  connected  to  the  NTBN.  (The  NTF  currently 
acts  as  the  hub  for  NTBN  communications.) 


2.2  SECURITY  DEFINITIONS 

The  definitions  were  drawn  from  the,  so  called,  Rainbow  Series  of  documents 
published  by  the  National  Computer  Security  Center  (please  see  reference  section  for  exact 
titles)  and  the  Merriam  Webster's  New  Collegiate  Dictionary. 

1)  Audit 

To  conduct  the  independent  review  and  examination  of  system  records 
and  activities. 

2)  Audit  Trail 

A  set  of  records  that  collectively  provide  documentary  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  fioward  to 
related  records  and  reports,  and/or  backwards  from  records  and  reports  to 
their  component  source  transactions. 


3)  Authentication 


1)  To  establish  the  validity  of  a  claimed  identity.  2)  To  provide  protection 
against  fraudulent  transactions  by  establishing  the  validity  of  message, 
station,  individual,  or  originator. 

4)  Data  Integrity 

1)  The  state  that  exists  when  computerized  data  is  the  same  as  that  in  the 
source  documents  and  has  not  been  exposed  to  accidental  or  malicious 
alteration  or  destruction.  2)  The  property  that  data  has  not  been  exposed 
to  accidental  or  malicious  alteration  or  destruction. 

5)  Discretionary  Access  Control  (DAC) 

A  means  of  restricting  access  to  assets  based  on  the  identity  of  system 
users  and/or  groups  to  which  they  belong.  The  controls  are  discretionary 
in  the  sense  that  a  user  with  a  certain  access  permission  is  capable  of 
passing  that  permission  (perhaps  indirectly)  on  to  any  other  user  (unless 
restrained  by  mandatory  access  control). 

6)  Identification 

A  means  of  establishing  an  AIS  users  identity  (generally,  a  link  between 
user's  computer  account  name  and  the  actual  identity  of  the  person(s) 
authorized  use  of  the  account). 

7)  Identification  and  Authentication  (I&A) 

A  means  of  linking  Identification  and  Authentication  methods  together  to 
act  as  a  single,  security-relevant  entity  (such  as  computer  logon  sequence 
that  requires  user's  computer  identification  and  password  to  be  given  prior 
to  providing  any  services). 

8)  Mandatory  Access  Control  (MAC) 

A  means  of  restricting  access  to  assets  based  on  the  sensitivity  (as 
represented  by  a  label)  of  the  asset  and  the  formal  authorization  (i.e., 
clearance)  of  users  to  access  information  of  such  sensitivity. 

9)  Privacy 

1)  The  ability  of  an  individual  or  organization  to  control  the  collection, 
storage,  sharing,  and  dissemination  of  personal  and  organizational 
information.  2)  The  right  to  insist  on  adequate  security  of,  and  to  define 
authorized  users  of,  information  or  systems. 

10)  Protection 

The  means,  methods  and  mechanisms  used  by  a  system  (AIS  in  this  case) 
to  reduce  or  eliminate  access  to  itself  or  its  resources  by  some  outside 
force  (usually  defined  as  an  unauthorized  force). 


2.3  CONCEPTS  OF  SECURITY 

These  concepts  of  security  arc  included  here  for  background  information  and  to  assist 
in  understanding  some  of  the  fine  points  of  security,  as  they  may  apply  to  the  NTB. 

2.3.1  Integrity 

The  concept  of  integrity,  as  here  addressed,  means  that  part  of  an  AIS  design  and/or 
implementation  that  concerns  itself  with  protecting  information  in  the  AIS  from  alteration  or 
destruction  by  an  agent  or  accident.  This  area  is  naturally  addressed  as  pan  of  security 
because  the  security  of  an  AIS  relies,  at  least  in  pan,  on  proper  labelling  of  information  and 


non-contamination  of  information.  Integrity  as  used  here,  however,  goes  beyond  what 
might  seem  as  the  natural  security  concerns.  It  also  addresses  issues  such  as* the 
believability  of  information  derived  from  computations,  consistency  of  data  bases,  correct 
information  transfers  across  networks,  and  protection  of  all  system  information  from 
corruptions.  The  Trusted  Network  Interpretation  (of  the  Trusted  Computer  Security 
Evaluation  Criteria,  or  TCSEC)  (TNI)  suggests  that  along  with  a  Secrecy  Policy,  some 
systems  will  need  an  Integrity  Policy.  The  NTB  is  certainly  one  of  those  systems. 

2.3.2  I&A  Beyond  Passwords 

Password-based  authentication  systems  are  vulnerable  to  a  variety  of  attacks  during  the 
life  of  the  passwords  such  as  those  associated  with  the  password  distribution,  selection, 
duration,  and  length.  Exploiting  the  vulnerabilities  in  the  password  system  can  result  in 
unauthorized  system  access.  The  user  identification  and  authentication  (I&A)  system  for 
the  NTB  should  be  in  addition  to,  or  a  replacement  for  the  standard  password  mechanism 
afforded  by  noost  existing  op^ting  systems.  Passwords  themselves  are  open  to  several 
known  flaws  (e.g.,  being  written  down,  being  easily  guessed,  wirertapping).  A  system 
that  either  replaces  passwords,  or  augments  them  can  strengthen  user  authentication  and 
identification.  Alternative  A&I  techniques  could  range  from  biometric  systems,  to  dumb 
cards,  to  smart  cards,  to  cryptographic  challenge! reply  systems. 

There  are  existing  biometric  systems  that  perform  retina  scans  of  the  inner  eye,  scan 
thumb  prints,  or  perform  combinations  of  various  biometric  analyses.  Dumb  cards  contain 
user  identity  information  encoded  in  a  magnetic  stripe.  The  most  common  form  of  this  card 
si  the  commercial  credit  or  automated  teller  machine  card.  Smart  cards  are  devices  that 
resemble  ordinary  credit  cards,  but  in  fact,  contain  a  microprocessor  and  memory.  The 
sman  card  can  implement  an  authentication  function  (via  encryption  algorithm)  that  can 
positively  identify  the  holder  of  the  card.  In  a  challenge! reply  system,  the  user  is  issued  a 
calculator-like  device  that  is  cryptographically  unique.  A  host  computer  system  issues  a  . 
challenge,  based  on  the  user's  claimed  identity.  The  user  inputs  the  challenge  into  the 
calculator-like  device,  and  then  types  a  reply,  generated  by  ^e  device,  back  to  the 
challenging  system. 

2.3.3  Risk  Assessment  And  Two  Methodologies 

No  security  system  is  perfect  (nor  should  any  system  be  considered  perfect).  The  risk 
that  remains  in  a,  proposed,  system  must  be  a.ssessed  and  found  to  be  acceptable,  by  some 
authority,  prior  to  processing  any  classified  information  on  that  system.  The  system's 
Designated  Approving  Authority  (DAA)  should  have  enough  information  about  the  residual 
risk  to  make  a  knowledgeable  decision  as  to  whether  the  system  should  be  authorized  to 
operate  or  not.  Risk  assessment  methods  are  also  used  by  system  designers  so  that  they  do 
not,  accidentally,  build  systems  with  insufficient  security.  There  are  several  different  risk 
assessment  methods  and  several  different  ways  in  which  their  outcome  is  presented.  The 
two  methods  briefly  discussed  here  both  provide  a  "risk  index."  The  two  methods  may 
come  out  with  different  results  (indices),  but  use  the  same  scale  and  so  can  be  compared. 
This  risk  index  provides  a  quantitative  measure  of  the  relative  "irustwonhiness"  of  a 
panicular  system. 

There  exists  two  primary  methods  for  determining  a  computer  system's  risk  index. 

One  method  is  defined  by  the  National  Computer  Security  Center's  "Guidance  for 
Applying  the  Depanment  of  Defense  Trusted  Computer  Systems  Evaluation  Criteria  in 
Specific  Environments"  (aka  the  "Yellow  Book").  The  other  method  was  defined  in  a 
Navel  Research  Laboratory  paper  entitled  "An  Approach  to  Determining  Computer  Security 
Requirements  for  Navy  Systems"  Carl  Landwehr  and  H.  0.  Lubbes.  The  two  approaches 
differ  in  that  the  "Yellow  Book"  takes  a  high  level  view  of  the  system  risk  (e.g.,  minimum 


level  of  user  clearance  versus  highest  level  data  processed)  whereas  the  NRL  paper 
includes  several  more  fine  detailed  aspects  of  system  processing. 

The  NRL  methodology  encompasses  all  of  the  Yellow  Book's  methodology,  but 
because  of  its  more  fine  grained  granularity,  is  ultimately  more  applicable  for  use  in  the 
Nra  environment  The  NRL  methodology  takes  into  account  various  types  of  system 
users  (e.g.,  programmers  versus  application  users),  and  their  method  of  communications 
with  the  system  (e.g.,  read-only  terminal,  dumb  terminal,  sman  (programmable)  terminal, 
interactive  connectivity,  batch  connectivity).  .This  provides  a  more  in  depth  risk  analysis 
and  could  result  in  a  less  stringent  set  of  security  requirements  based  on  tiie  environmental 
usage  of  the  system. 

To  the  greatest  extent  possible,  the  NRL  method  should  be  used.  Situations  that  make 
the  e.xact  level  of  vulnerability  unclear,  should  either  be  further  clarified  or  the,  more  strict, 
"Yellow  Book"  interpretation  should  be  used. 

2.3.4  Communities  of  Interest  (COI) 

Based  on  the  capabilities  and  intended  use  of  NTB  assets,  there  will  be  many  NTB 
users  with  varying  clearance  levels  and  affiliations.  The  NTB  can  accommodate  these 
users  by  partitioning  its  assets  into  segments  that  are  appropriate  for  subgroups  of  users. 
These  subgroups  are  referred  to  as  Communities  of  Interest  (COI).  A  COI  can  be  defined 
by  three  entities: 

1)  A  group  of  NTB  users  with  common  access  characteristics 

2)  A  set  of  NTB  hardware  assets 

3)  A  collection  of  software  and  data 
Examples  of  COIs  would  include  the  following: 

NTB  software  development  teams  (One  COI  for  each  contracting  firm) 

NTB/JPO  administrators 

Experiments  (If  isolation  from  general  community  is  desired) 

Exercise  Participants  (One  COI  for  each  side  to  aid  in  separation) 

Defining  COIs  will  be  the  joint  responsibility  of  the  accessing  organization  and  the 
NTB  system's  administrator  (with  input  from  security).  Whatever  the  basis  for  the  COI, 
whether  it  be  a  common  project,  sub-project,  or  function,  the  list  of  individuals  will  be 
checked  for  appropriate  clearance  and  need-to-know  for  the  aggregate  of  information  to  be 
available  to  the  COI.  Each  COI  member  will  have  access  to  all  assets  allocated  to  the  COI 
by  a  combination  of  physical  access  controls  on  the  NTB  assets  and  user  privileges  granted 
by  the  NTB  Administrator. 

2.3.5  Partitioning 

The  general  concept  of  partitioning  is  the  separation  of  information,  based  on  some 
criteria.  (I.e.,  DoD  Classification  of  information)  Whether  the  separation  is  done 
electrically,  electronically,  or  in  software,  all  are  considered  "partitioning."  Here,  it  will 
mean  the  separation  of  infonnation,  by  appropriate  means,  over  the  range  of  classification 
of  information  authorized  for  a  particular  Automated  Information  System  (AIS). 

In  Partitioned  Mode,  all  system  users  must  be  cleared  to  a  "High  Water  Mark" 
classification  level  (for  the  NTB,  Secret),  but  not  all  would  necessarily  be  authorized  access 
to  all  compartments  on  the  system.  This  removes  some  constraints  on  system  interactions 


between  different  sites  (nodes,  for  the  NTBN)  by  only  requiring  authorization  to  those 
compartments  that  are  needed,  rather  than  authorizadon  to  all  compartments(as  would  be 
necessary  in  Dedicated  Mode).  For  example,  a  Panitioned  Mode  NTBN  would  allow  users 
who  are  not  formally  authorized  for  both  CNWDI  and  WNINTEL  data  to  use  the  NTBN 
(wi±in  the  confines  of  the  appropriate  security  policy).  This  mode  will  also  suppon 
additional  compartments,  as  required,  without  affecting  existing  users. 

2.3.6  Multilevel  Secure  (MLS) 

One  can  have  a  system  that  processes  multiple  levels  of  classified  information,  but  not 
try  to  "keep  it  straight"  in  software  (i.e.,  panitioning).  But,  in  order  to  process  multiple 
classifications  of  information  (e.g..  Top  Secret  through  Confidential),  simultaneously, 
without  requiring  all  users  to  be  cleared  to  the  highest  level  of  data  being  processed,  a ' 
Mulrilevel  Secure  (MLS)  system  is  required.  MLS  systems  entail  security  functionality 
such  as  mandatory  and  discretionary  access  controls  (MACVDAC),  audit,  and  I&A. 
Associated  with  the  required  MLS  functionality  is  the  assurance  that  the  MLS  mechanisms 
are  designed  and  implemented  correctly.  The  measure  of  security  functionality  and  design 
correctness  results  in  a  security  evaluation  rating  as  described  in  the  TCSEC  and  the  TNI. 
among  other  places. 

2.3.7  Provision  of  Service 

Provision  of  Service,  or  system  availability,  is  the  dual  of  protection  against  denial  of 
service.  Denial  of  Service  is  defined  as  the  means  by  which  a  system  user,  or  a  process 
acting  on  behalf  of  a  system  user,  can  slow  down  or  shut  dov/'a.  system,  thereby  denying 
system  services  to  all  other  system  users.  Provision  of  Service  can  be  defined  as  the  setV 
mechanisms  used  to  prevent  Denial  of  Service  attacks.  Denial  of  Service  is  a  threat  to  both 
networked  systems  as  well  as  stand-alone  systems  but  has  a  far  more  reaching  effect  in  a 
networked  environment.  This  is  due  to  scaling  factors  -  users  of  the  network  have  many  • 
systems  available  for  use.  Those  systems  contain  a  great  deal  of  data  -  much  more  so  than 
would  be  available  on  a  single  stand-alone  system.  Therefore,  when  service  is  denied  to 
the  network,  many  more  users,  systems,  and  amounts  of  data  are  negarively  effected.  In  a 
network,  there  is  a  greater  threat  of  a  denial  of  service  attack  because  of  the  addition  of 
ubiquitous  communications  services.  In  addition  to  denying  service  to  individual  computer 
systems,  the  threat  exists  to  deny  communicarion  services  tetween  computer  systems. 

2.3.8  System  Models  For  Security 

As  can  be  seen  in  Figure  2-1,  Conceptual  Secure  Component,  conceptually  it  is  simple 
to  secure  something.  Application  to  a  particular  component  of  an  Automated  Information 
System  will  not,  in  practice,  be  so  straight  forward.  The  general  case,  however,  provides 
the  basis  for  understanding  how  this  concept  would  work  in  the  specific  case  and  thus  is  a 
good  place  to  stan. 


Figure  2-1,  Conceptual  Secure  Component 

The  generic  box  identified  as  INTERFACE  is  meant  to  provide  a  placeholder  for 
whatever  it  takes  to  "get  to"  a  panicuiar  ASSET.  The  ACCESS  CONTROL  represents 
whatever  security  measures  have  been  included  to  protect  the  ASSET,  Limit  access  to  it  and 
control  the  way  in  which  the  world  interacts  with  it.  Examples  of  INTERFACES, 

ASSETS  and  their  ACCESS  CONTROL  would  include: 

INTERFACE  ACCESS  CONTROL  ASSET 

Door  to  a  room  Lock  on  door  Personal  computer 

Log-on  routine  Password  and  I&A  Stand-alone  computer 

LAN  protocols  Label  put  on  by  LAN  Network  of  computers 

These  few  examples  are  given  to  provide  a  basis  for  understanding.  The  following 
sections  will  provide  additional  detail.  Below  is  a  list  of  access  control  features  that  may  be 
present  in  one  or  more  of  the  access  control  areas: 

MAC  Policy  Enforcement 
DAC  Policy  Enforcement 
Separadon  Policy  Enforcement 
Isolation  Policy  Enforcement 
Privacy  Policy  Enforcement 
Audit  Policy  Enforcement 
I&A  Policy  Enforcement 

Figure  2-2,  System  Element  Roadmap,  is  a  stick-figure  of  a  system  that  has  all  the  elements 
we  are  interested  in,  namely:  Hosts  (computers),;  LANs;  WANs;  and  Nodes  (collections 
of  Hosts  and  LANs,  possibly,  connected  by  WANs).  Figure  2-3,  Element  Roadmaps, 
gives  a  decoupled  view  of  each  of  the  parts.  The  Node  element  will  be  used  in  most  of  the 
following  subsections  as  our  "map"  of  the  system  to  aid  in  understanding  just  where  we 
are. 


Figure  2-2,  System  Element  Roadmap 


System 


Host  (Computer) 


Figure  2-3,  Element  Roadmaps 


2.3.8. 1  Hosts 

From  Figure  2-4,  Secure  Host  Example,  the  representation  of  the  host  may  seem 
overly  simplistic  (considering  the  average  complexity  of  most  computers  and  their 
hardware  and  software  environments).  This  was  done  purposefully  to  provide  focus.  The 


simple  model  in  the  figure  must  be  applied  to  the  computer  and  to  each  hardware  or 
software  component  of  it  separately.  For  example,  there  will  be  word  processors  that 
manipulate  text  in  files.  The  interface  to  the  file  is  the  set  of  commands  initiated  by  the  user 
and  conducted  by  the  word  processor.  The  access  control  mechanism  could  be  in  three 
pans.  The  fint  pan  could  be  that  within  the  word  processor,  itself  (if  it  were  properly 
written).  It  would  check  the  user's  privileges  to  make  the  requested  changes.  The  second 
pan  would  be  the  Operating  System.  It  would  check  to  see  if  the  user  (not  the  word 
processor)  is  permitted  to  make  the  requested  changes.  The  third  pan  might  be  the 
Information  storage  system,  itself  (secure  file  manager  or  DBMS).  It  might  check  the 
user's  privileges  to  make  the  requested  changes.  At  least  the  second  would  be  done,  in  a 
secure  environment. 

Access  Control; 

Secure  Operating^V,. 

System  ^ 

Asset:  _ 

General  Tools^^*'''''''’'''''^ 

Compilers,  Editors,  Etc. 

Files: 

System  Files,  User  Files. 

Interface: 

User  Teminal  Connection 

LAN  Connection 

Figure  2-4,  Secure  Host  Example 


2.3. 8.2  LANs 

In  Figure  2-5,  Secure  LAN  Example,  the  network  is  represented  as  an  "active  cable" 
(i.e.,  the  cable  plant  and  a  front  end  to  the  network  for  each  asset  that  must  have  its  own 
identity,  on  the  network).  Good  examples  of  different  types  of  connectivity  are:  Each 
host/computer  in  A  Computer  Room  would  have  its  own  front  end  to  the  secure  LAN.  so 
each  computer  can  be  addressed  individually  (and  securely);  Single  use  "LABs"  might 
have  a  single,  "secure  front  end,"  so  all  the  assets  in  the  LAB  are  seen  as  a  single  entity,  for 
security  purposes;  A  large  lab  divided  into  multiple,  smaller  work  areas,  where  each  small 
area  would  have  its  own  secure  front  end,  separate  from  the  others.  These  represent 
imponant  decisions  where  resources  (many  or  few  at  a  time)  are  seen  as  a  single  entity  and 
thus  only  available  to  a  single  group  of  users  at  any  one  time.) 


Access  Control: 
Secure  Interface 
Asset: 


Computer 

Interface: 

Network  Protocol 
Suite 


Figure  2-5,  Secure  LAN  Example 


2. 3. 8. 3  WANs 

In  Figure  2-6,  Secure  WAN  Example,  the  WAN  is  represented  as  the  communications 
media  between  sites  that  contain  hosts  and  LANs.  This  is  true,  but  misleadingly  simple. 
The  WAN  "cable  plant"  may  well  represent  many  interconnected  cables  (including  other 
WANs  and  LANs)  with  tremendous  complexity.  The  simplistic  representarion  here  is  for 
three  reasons.  The  first  reason  for  the  reduction  of  any  complexity  is  to  provide  a  vehicle 
for  discussion  without  getting  bogged  down  in  detail,  immediately.  The  second  reason  to 
avoid  complexity  at  this  level  is  to  permit  an  "implementation-free"  environment  to  assist  in 
getting  all  ideas  "on-the-table."  The  third  reason  is  that,  regardless  of  how  one  makes  the 
WAN,  it  will  be  all  but  transparent  to  the  user  (witness  the  current  end-to-end  encryption, 
and  each  currently  proposed  replacement  that  has  similar  features).  The  import  security 
features  of  the  secure  WAN  are  the  protection  of  and  integrity  of  the  information  that  transit 
the  WAN. 


Access  Control: 

Bulk  Encryption 
& 

Routing  Info. 


Asset: 

A  Set  of  LANs  at 
a  Node 


□ 


Interface: 

Long  Haul  Communications 
Media  and  Protocols 

Figure  2-6,  Secure  WAN  Example 


2. 3. 8. 4  Systems 

Secure  systems  can  be  addressed  as  a  sum  of  their  pans.  That  is,  they  can  be  built  out 
of  secure  hosts,  secure  LANs  and  secure  WANs.  Any  additional  "glue"  between  pans 
general  can  be  placed  in  one  of  the  above  categories.  The  way  one  differentiates  between  a 
secure  system  and  pans  is  the  paperwork  involved.  In  general,  a  system  will  have  security 
policy  statements  for  all  security  relevant  issues  to  be  addressed  by  any  pan  of  the  system. 


Different  pans  may  address  all  or  some  of  any  pan  of  the  system’s  security  policies  A 
pod  discussion  on  the  building  of  secure  systems  can  be  found  in  the  Trusted  Network 

aka  Red  Book)  of  the  Trusted  Computer  Securitv  Evaluation  Cnteria 
(TCSEC,  aka  Orange  Book). 


2.4  SECURITY  MANAGEMENT 

Management,  the  sphere  of  influence  for  the 

NTB  Management  encompasses  all  NTB  Member  assets,  whether  connected  to  the  NTBN 
or  not,  and  the  interface  to  the  Customer  Community.  What  is  meant  by  this  is  that  there 
must  be  a  way  of  scheduling  resources,  across  the  entire  NTB,  in  such  a  way  as  to  be  more 
efncipt  in  providing  sewices  to  the  greater  community  of  users  (in  practice,  this  means 
that  there  must  be  coordination  between  sites/nodes  in  scheduling  resources  and  there  must 
be  general  agreement  across  all  sites/nodes  as  to  the  mission  of  the  NTB)  The  difference 
between  an  NTB  Member  and  a  Customer  of  the  NTB  will  be  discussed  in  the  next  section 


Boundary  of  Responsibility 

Rgure  2-7,  NTB  Management 

2.4.1  Member  Vs  Customer 

The  simplest  way  to  delineate  between  members  and  customers  of  the  NTB  is  to  say 
that  entities  whose  funding  is  provided,  to  some  extent,  by  SDIO  are  members  of  the  NTB 
-  all  others  who  wish  to  use  the  NTB  are  considered  customers.  These  simple  definitions 
work  well  within  the  security  environment,  since  there  is  a  sense  of  responsibility  to 
provide  security  assistance  to  any  entity  that  is  funded  by  the  SDIO,  that  requests  it,  and  a 
sense  that  all  others  should  pay  for  such  service(s),  as  well  as  any  other  NTB  resources 


2.4.2  Memorandum  of  Agreements  (MO As) 

Here  we  define  the  MOA  as  the  formal  mechanism  used  to  document  the  mutuallv 
agreed  to,  connectivity  between  two  NTBN  Nodes.  In  this  agreement,  security  must  be 
addressp  to  include:  level(s)  of  classified  information  that  ca  be  exchanged  or  stored  at 
each  facility,  level(s)  of  processing  of  information  at  each  node^  and  some  agreement  as  to 
what  labels  will  be  used  for  the  information. 


2.4.3  NTF/NTB  Coordination  Groups 

There  has  been  a  perception,  real  or  imagined,  that  the  NTB  in  general,  and 
.specifically  the  NTF  are  difficult  to  connect  to  and  use.  The  NTF  Coordination  Group 
(NTFCG,  or  for  now  simply  NCG)  was  formed  to  address  these  views,  at  the  NTF  (and 
its  users)  level.  The  NTB  Coordination  Group  (which  has  not  been  formed,  yet)  will  be  a 
NTB-level  version  of  the  NTF  group,  thus  serving  the  endre  NTB  community. 

2.4.3. 1  NTF  Coordination  Group 

The  NTFCG  is  the  central  coordinaring  group  for  all  initial  project  requiremems 
definitions  and  resource  forecasts.  It  coordinates  the  long-  and  shon-range  schedules  of  all 
NTF  resources  and  is  responsible  for  recommending  and  applying  scheduling  priorities  in 
accordance  with  NTB/JPO  and  SDIO  policy.  A  list  of  all  NTF  project  account  numbers  vs. 
contract  numbers  and/or  responsible  government  agencies  is  kept  to  assist  in  validation  of 
active  accounts  and  projected  needs.  It  also  maintains  utilization,  allocation,  and 
accounting  data  for  all  projects  at  the  NTF  and  provides  repons  based  on  that  data.  In  this 
role,  they  also  will  need  to  be  aware  of  the  security  implications  of  proposed,  new  users  as 
well  as  the  current  security  status  of  the  NTF. 

2.4.3.2  NTB  Coordination  Group 

The  NTB  Coordination  Group  will  be  fashioned  after  the  NTFCG,  learning  from  its  , 
mistakes  and  successes.  It  will  be  a  team  of  representatives  from  each  of  the  sites  of  the 
National  Test  Bed  (both  NTBN  Nodes  and  sites  that  are  not  nodes  of  the  NTBN).  NTB- 
wide  resource  management  issues  would  be  discussed  and  resolved  in  this  organization. 


3.0  METHODOLOGY 

The  methodology  documented  in  this  section  is  the  result  of  a  critical  analysis  of  what 
has  worked  (and  not  worked)  in  past  anempts  at  applying  good  system's  engineering  and 
analysis  techniques  to  the  area  of  security.  It  would  also  seem  to  apply  for  any  system- 
widfe  problem  that  crosses  traditional  disciplinary  boundaries  (unlike  software  system 
problems,  but  like  software/hardware  integration  issues). 

The  securing  of  the  NTB  is,  at  best,  a  mammoth  task.  Critical  decisions  will  be 
required  involving  key  decision  makers.  These  key  decision  makers,  will  not  have  the  time 
or  extensive  backgrounds  necessary,  to  directly  affect  an  implementable  security  architecture 
(and  indeed,  this  is  not  their  role).  They  do,  however,  have  a  responsibility  to  the  NTB 
community  to  make  the  NTB- wide  decisions  (such  as:  what  constitutes  "enough"  security; 
in  what  security  mode  will  the  NTB,  as  a  whole,  operate  at;  and  how  do  the  pans  of  the 
NTB  interact,  with  respect  to  security).  They,  therefore,  must  find  an  efficient,  cost 
effective,  methodology  that  will  provide  them  with  sufficient  information  (technical,  cost, 
and  schedule)  to  permit  them  to  make  reasonable  decisions  in  a  timely  fashion.  The 
methodology  presented  below  would  suppon  such  a  process. 


3.1  EXPLANATION  OF  METHODOLOGY 

The  seven  step  process  identified  here  sets  a  course  of  action  that,  if  followed,  will 
provide  the  information  sufficient  so  that,  along  with  the  consensus  of  the  community,  a 
reasonable  decision  can  be  made.  It  is  present^  here  in  a  generic  form.  The  next  section 
will  tailor  it  to  the  solution  of  the  security  challenges  at  the  NTB. 

-  Step  1:  Define  Purpose 

-  Coals  to  Achieve 

Step  1  provides  the  focus  for  the  Teams’  evaluation.  The  key  decision  makers  shall 
set  the  goals  and  select  the  Core  Team  and  the  Audit  Teana  The  goals  identify  the 
destination.  The  Core  Team  will  builds  the  road.  The  Audit  Team  provides  appropriate 
technical  review. 

-Step  2:  Select  Core  and  Audit  Teams 

-  Identify  Areas  of  Required  Expertize 

-  Identify  Areas  of  Engineering  Discipline 

-  Identify  User  Representation 

The  Teams  will  be  selected,  by  the  key  decision  makers,  based  on  the  expertise 
required  by  the  purpose  of  the  evaluation.  Each  area  must  be  represented  to  ensure  a  high 
level,  wide  perspective  on  the  purpose. 

-  Step  3:  Collect  Information 

-  Establish  criteria 

-  Gather  important  information  from  all  areas 

-  Each  team  merrdter  brings  a  piece  of  the  puzzle 
•  Any  other  “parties"  that  may  be  concerned  are  identified 

Step  3  is  critical  to  the  success  of  the  evaluation.  The  Core  Team  must  first  agree  on 
the  criteria  by  which  potential  solutions  will  be  judged.  This  too  will  be  shaped  by  the 
purpose  of  the  evaluation.  Early  agreement  will  maintain  the  focus  and  keep  the  Core  Team 
on  track.  Next  each  Core  Team  member  researches  and  brings  information  from  his/her 


area.  From  this  information,  potential  solutions  are  drawn.  The  criteria  will  be  screened 
by  the  key  decision  makers  and  the  Audit  Team,  prior  to  beginning  Step  four. 

-  Step  4:  Evaluate  Information  Against  Criteria 

-  Models  are  presented 

•  User  requirements  are  presented 

-  Engineering  parameters  are  specified 

-  Specific  Areas  capabilities  are  presented 

-  Additional  considerations  are  presented 

The  evaluation  step  will  begin  to  identify  which  proposed  solutions  are  possible.  Each 
area  is  evaluated  and  each  solution  is  measured  for  its  ability  to  withstand  repeated  attacks. 

-  Step  5:  Develop  Pros  and  Cons 

-  Solicit  outside  review  in  each  area 

-  Incorporate  results  of  solicitation 

The  documentation  begins  by  listing  the  areas  where  each  solution  failed  to  stand  up  to 
the  criteria.  The  Pros  and  Cons  are  listed  and  presented  to  the  Audit  Team.  This  is  done  to 
ensure  the  Core  Team  did  not  get  "wrapped  around  the  axle"  with  internal  bias.  The 
comments  from  the  Audit  Team  are  noted  and  the  Core  Team  returns  to  evaluate  for 
consistence,  (consistency) 

-  Step  6:  Determine  Risk  of  Implementation 

•  Solicit  outside  review  in  each  area 

-  Incorporate  results  of  solicitation 

Since  the  world  of  MLS  technologies  is  just  evolving,  there  will  be  risks  associated 
with  each  solution.  The  Core  Team  will  determine  those  risks  based  on  the  criteria, 
evaluation,  pros  and  cons,  and  the  outside  team  input.  This  again  will  be  presented  to  the 
Audit  Team  for  another  sanity  check. 

•  Step  7:  Report  Findings 

-  Present  concrete  actions  for  implementation 

•  Follow  up  on  (monitor)  implementation 

The  repon  ties  the  whole  process  back  together.  Here  the  solutions  are  described  as 
how  they  answer  the  purpose  of  the  evaluation.  They  are  ranked  by  the  most  effective 
solution  to  the  least.  From  this  repon.  Senior  NTS  decision  makers  will  be  able  to  make 
an  informed  decision  based  on  a  systemic  process  of  evaluating  incomplete  information. 


3.2  IMPLEMENTATION  OF  METHODOLOGY 

It  is  envisioned  that  any  follow-on  effon  dealing  with  securing  the  NTB  will  follow 
the  above  methodology.  Chaners  for  each  group  should  be  drawn  up  from  the  description 
of  each  ones'  task(s).  The  importance  of  Step  1.  Define  Purpose,  must  be  stressed.  The 
people  putting  together  the  teams  (presumably  a  combination  of  prospective  team  members 
and  the  key  decision  makers)  should  define  the  purpose  prior  to  any  team  member 
assignment  or  other  action  on  behalf  of  the  team  or  its  effon(s).  Once  the  key  decision 
makers,  those  responsible  for  a  particular  area  (or  "opponunity"  facing  the  NTB),  have 
been  identified/appointed  they  should  set  down,  in  writing,  the  purpose  of  the  effon  they 
are  undertaking.  They  should  also  identify  the  goals  of  the  effon  (of  course,  after  seeking 
technical  input  for  this  pan,  from  potential  team  members).  Both  the  purpose  and  the  goals 
statements  can  be  revisited  during  the  effort,  however,  they  should  not  be  changed  without 
quit  a  bit  of  considered  thought,  since  it  on  the  basis  of  these  statements  that  the  team 
members  were  selected. 


Once  the  purpose  and  the  goals  statements  have  been  written,  the  team  member  choices 
should  be  finalized.  Each  member  of  each  team  should  bring  one  or  more  expertise  in  areas 
that  are  vital  to  the  completion  of  the  teams'  tasks.  Particular  care  should  be  taken  in 
picking  the  Audit  Team  members.  They  will  have  to  "come-up  to  speed"  quickly,  when 
they  review  the  Core  Teams'  efforts  (without  a  lot  of  time  to  do  background  information 
gathering).  For  any  follow  on  to  the  NSSWG's  effon,  the  following  areas  must  be 
addressed: 


Communications 

Operations 

Security 

Systems  Engineering 
User  Community 

The  NSSWG  has  already  looked  briefly  at  user  requirements  that  dictate  improved 
.system  security.  However,  what  is  meant  by  a  "criterion"  is  a,  more  in  depth,  look  at  all 
the  pans  of  the  system  and  its  users.  The  Core  Team  (perhaps  with  assistance  from  some 
Audit  Team  members)  will  have  to  "beat-the-bushes"  in  order  to  collect  a  reasonably 
complete  criteria  against  which  to  evaluate  solutions.  This  is  so  because  the  NTB  is  an 
ever-changing  set  of  assets  that  may  or  may  not  have  exactly  the  same  mission's  statements 
(each  asset  can,  in  fact,  have  a  different  focus  even  when  there  is  a  common  mission,  e.g., 
one  host  may  be  running  a  threat  environment  scenario  while  another  emulates  a  command 
and  control  center  -  they  could  be  working  on  the  same  problem,  but  have  completely 
different  needs  with  respect  to  security). 

Evaluation  of  a  potential  solution,  against  the  criteria,  is  a  crucial  step  in  the  process. 
Sufficient  information  about  each  proposed  solution  (in  some  amount  of  detail)  must  be  • 
available  in  order  to  allow  a  reasonable  evaluation.  The  following  kind  of  information 
should  be  available  about  each  system  security  solution  (as  a  minimum): 

A  System  Security  Model  is  presented 
User  requirements  are  presented 
Engineering  parameters  are  specified 
Required  capabilities  are  presented 
Communications 
Security 
Operadonal 

Additional  considerations  are  presented 
Communications 
Security 
Operational 

In  developing  pros  and  cons  and  evaluating  risks,  the  two  teams  will  have  to  be  careful 
to  keep  their  roles  straight.  The  difficulty  here  is  expected  to  be  with  the  Audit  Team  who, 
certainly  being  technically  qualified,  suggests  "solutions"  not  thought  of  by  the  Core  Team. 
Care  must  be  taken  in  this  environment.  Either  the  Core  Team  and  Audit  Team  must, 
momentarily  "switch  places"  (with  the  Core  Team  now  critically  analyzing  a  proposed 
solution  through  both  the  pros  and  cons  step  and  the  risks  assessment  step)  or  individual 
members  of  the  teams  must  "switch"  with  respect  to  this  particular  point  (not  advised). 

All  the  steps  are  vital,  however,  if  Step  7  is  not  properly  done,  all  the  other  steps  are 
u.seless.  The  reporting  of  the  findings  of  the  teams  (not  just  their  conclusions,  but  how 
they  reached  them)  should  be  given  as  wide  as  distribution  as  possible.  They  will  serve  to 


assist  others  who  may  be  trying  to  solve  the  same  kinds  of  problems  and  may  even  apply  in 
other  problems  within  the  SDI  program. 

Although  meetings  should  not  be  used  to  simply  "get  the  team(s)  together,"  the 
NSSWG  has  found  shon  meetings,  or  even  Video-Teleconferences  (VTC),  to  be  very 
useful.  We  found  that  shon-fuse  tasking,  and  "quick-looks"  at  even  complicated  topics, 
with  repons  back  to  the  group  (of  even  intermediate  results)  helped  keep  the  group 
focu.sed.  The  idea  of  keeping  every  team  member  informed  and  "up-to-date"  on  any 
changes  is  vital  so  as  to  not  waste  the  team's  time,  when  meetings  are  called.  (Also,  with 
each  member  looking  at  new  information  before  meetings,  the  meetings  will  be  more 
fruitful). 

The  NSSWG  also  found  that,  if  one  could  draw  a  picture  of  a  subject  under  discussion 
or  an  idea  that  was  put  forth,  it  was  easier  to  involve  the  entire  team,  rather  than  just  talking 
about  a  subject.  In  the  next  section  some  of  the  "strawman  architectures"  that  were 
developed  are  presented. 


4.0  STRAWMAN  ARCHITECTURE 

From  the  discussion  on  the  Conceptual  Secure  Component,  it  should  now  be  clear  that 
at  any  given  place  in  a  system  architecture,  one  can  identify  a  security  relevant  component 
by  describing  its  task(s)/function(s).  Funher,  to  assist  in  efficient  placement  of  such 
components,  one  need  only  look  for  potential  boundaries  between  two  "groups."  Whether 
these  groups  are  different  user  groups,  with  different  security/data  needs,  or  these  "groups" 
delineate  the  difference  between  an  authorized  system  user  and  an  unauthorized  user  will 
assist  one  in  determining  what  level  of  precaution  (security)  on  the  AIS  should  apply.  To 
assist  in  this  effon,  a  policy  of  the  type  of  security  to  be  enforced  at  a  particular  place 
should  be  identified/provided.  An  example  of  this  would  be  a  Mandatory  Access  Control 
Policy  statement  about  user’s  access  to  assets  which  could/would  be  enforced  in  each  path 
provided  the  user  for  connecting  to  the  assets,  like  on  the  computers,  themselves,  the 
network  that  connects  the  user  to  the  computer,  or  both. 

In  each  architecture  picture  in  the  following  subsections,  an  asterisk  (♦)  has  been 
placed  at  a,  potential,  security-  relevant  boundary.  In  the  WAN  Figures,  connections 
between  sites  have  asterisks  on  them,  indicating  some  form  of  security  is  required  there 
(currently,  bulk  encryption  is  used  between  connected  sites).  In  the  "NTF"  Figures,  there 
are  several  kinds  of  toundaries  indicated  by  asterisks.  On  the  outside  edge  of  the  NTF, 
there  are  the  boxes  with  asterisks  in  them.  These  boxes  represent  equipment  that  must 
provide  the  NTF  interface  to  the  "outside  world."  One  such  set  (with  ’Tl"  next  to  them 
represent  one  end  of  the  inter-Node  connection  shown  in  the  WAN  Figures  (that  currently 
use  the  bulk  encryption).  These  will  be  further  explained  in  the  following  subsections. 
Implicit  in  the  "Tl"  box  connecting  to  the  interior  of  the  NTF  (and  PSN)  and  explicitly  in 
front  of  the  Hosts  in  Computer  Room  1  and  in  front  of  the  other  LABs,  there  are  secure  • 
LAN  "Front  Ends."  Whether  these  are  separate  boxes  of  equipment  to  secure  the 
connection  of  the  assets  and  protect  the  information  over  the  cable  plant  or  a  board  inside  a 
panicular  computer  is  irrelevant  to  this  discussion.  Only  the  functionality  they  provide  is 
important  (obviously,  this  luxury  does  not  extend  to  the  security  engineers  that  will  be 
charged  with  implementing  the  "enhanced  security"  discussed  here).  We  give  as  a 
baseline,  the  following  two  figures:  Figure  4-1,  Current  WAN  and  Figure  4-2,  Current 
Node,  so  that  proposed  "improvement"  measurements  may  have  some  common  base. 


4.1  NOW 

By  "Now"  what  is  meant  is  those  system  security  capabilities  that  could  be  planned 
and  implemented  within  one  to  three  years  that  would  improve  the  general  security  posture 
of  the  NTBN  and  its  nodes  (using  the  NTP  as  a  guinea  pig).  Of  particular  interest  are 
things  that  could  be  done  sooner  still.  For  example,  the  proposed  LAN  implementation  is 
possible  now,  using  one  of  several  Off-The-Shelf  (OTS),  NSA  approved  secure  LAN 
products.  In  general,  however,  more  planning  and  analysis  is  needed  before  any  decision 
can  be  made. 

The  WAN  picture.  Figure  4-3,  WAN  Example  2,  shows  the  NTBN  with  extensions. 
Note  the  obvious  inclusion  of  two  WANs,  represented  by  DISNET  (Secure)  and  Internet 
(Unsecure).  These  are  representational  -  any  classified  robust,  nation-wide 
communications  network  could  replace  DISNET  in  the  figure.  TTie  same  is  true  for  Internet 
(any  robust,  unclassified,  nation-wide  network  could  take  its  place  in  the  figure).  The 
connections,  in  the  figure,  to  various  NTBN  Nodes  were  picked  to  show  all  the  different 
kinds  of  nodes  that  could  be  connected  and  is  not  meant  to  be  a  suggestion  list.  The 
communications  between  NTBN  Nodes  over  the  DISNET  connection  would  similar  to  the 
current  communications  with  only  a  few  exceptions  (albeit  important  ones).  The  "back 
bone"  of  the  current  NTBN  (see  figure  Current  WAN)  is  the,  cumulative,  set  of  T1  lines, 
that  form  dedicated  links  between  the  NTF  Node  and  other  Nodes  of  the  NTBN.  A  break 
down  of  a  single  piece  of  communications  gear,  anywhere  between  the  NTF  and  another 
Node,  completely  isolates  that  other  node  from  the  rest  of  the  NTBN.  With  DISNET,  even 
if  connection  is  lost  over  a  panicular  sub-link,  a  new  path  can  generally  be  established. 

Also,  Connection  to  DISNET,  or  a  similar  secure  network,  requires  a  Secure  WAN  front 
end,  like  a  Blacker  device,  which  suppons  Type  1  encryption  and  still  provides  the  routing 
information  required  by  DIS NET'S  Pack  Switched  Networks.  This  gives  us  the  same  level 
of  protection  on  those  WAN  interfaces  that  we  have  now  (Type  1  encryption)  and  yet  also 
provides  routing  information  (not  available  with  our  bulk  encryptors)  ^at  suppon  the 
multiple  routing  over  the  WAN,  owned  and  operated  by  someone  else. 


Even  though  the  connection  to  the  Internet  would  be  operating  at  the  Unclassified 
level,  some  form  of  security  (represented  by  the  asterisk  on  the  right  hand  side  of  the  NTF, 
in  the  WAN  picture.  Figure  WAN  Example  2),  will  be  implement  to  ensure  SDI-only, 


related  unclassified  traffic  is  processed  by  the  system.  This  will  limit  the  vulnerability  of 
the  system  from  potential  abusers  while  still  allowing  E-mail  and,  authorized,  remote 
system  log-ons,  at  the  Unclassified  level. 

On  the  Node  picture.  Figure  4-4,  Node  Example  2,  all  of  the  "external  lines"  coming 
to  the  NTF  Node,  in  the  WAN  picture,  are  now  those  lines  penetrating  the  "wall"  of  the 
NTF.  Note  that  each  box  labeled  with  "T1 "  has  an  asterisk.  These  represent  the  WAN 
termination  equipment  at  a  node  (the  NTF.  in  this  case)  which  would  have  some  security 
significance  (or  responsibility).  And,  note  the  box  labeled  "DISNET"  has  an  asterisk  in  it 
to  remind  us  that  it  to  is  a  security  relevant  boundary.  Note,  also,  the  "Dial-In  With  STU 
111"  box  has  an  asterisk.  Obviously,  here  the  STU  III  is  operating  in  the  role  of  bulk  data 
encryption  unit  on  an  non-permanent  basis  (the  connection  to  the  remote  site  is  broken  and 
re-established  as  needed,  unlike  the  dedicated,  full-time  "Tl"  Lines.  Also,  note  the  boxes 
with  asterisks  at  the  entrance  to  "LAB"  and  "Computer  Room  2"  and  internal  to  "DESC." 
These  represent  LAN  security  boxes  that  can  separate  one  lab,  or  group,  from  another. 
Note  that  the  same  kind  of  network  box  is  in  front  of  each  asset  in  Computer  Room  1. 

This  obviously  indicates  that  each  asset  in  Computer  Room  1  can  be  in  its  own  group.  (If 
there  were  only  a  LAN  box  in  front  of  the  whole  computer  room  {like  the  case  of  "LAB"), 
all  of  the  assets  in  Computer  Room  1  could  only  service  one  group  of  users  at  a  time,  while 
all  other  groups  would  have  to  wait.)  There  are  also  two  special  purpose  boxes  in  the 
figures  that  are  identified  by  function:  a  gateway/guard  (G/G)  and  a  one-way  gate  (OWG). 
The  names  are  descriptive  of  the  propenies/functions.  ITie  G/G  acts  as  a  "security  guard" 
at  a  gate  might.  It  checks  traffic  going  either  direction  to  ensure  that  the  traffic  is:  1) 
permissible;  and  2)  properly  labeled.  Traffic  that  passes  the  inspection  is  let  through.  If 
some  traffic  doesn’t  pass,  the  G/G  repons  it  and,  usually,  discards  it.  As  its  name  implies, 
the  OWG  acts  like  a  G/G  except  traffic  is  restricted  to  a  single  direction. 


In  the  next  WAN  picture.  Figure  4-5,  WAN  Example  3,  there  are  multiple  Packet 
Switched  Networks  (PSN).  Note  that  the  PSN  that  is  noted  as  being  "Located  at  the  NTF" 
has  only  a  single  interface  box  with  an  asterisk  in  it  (the. box  that  connects  it  to  the  NTF 
box).  The  meaning  of  this  will  become  clear  when  one  looks  at  the  next  Node  picture. 


Figure  Node  Example  3.  There  is  not  other  difference  between  this  WAN  picture  and  the 
last  one.  However,  as  will  be  seen  in  the  Node  picture,  this  one  change  has  both  security 
and  operational  impacts  on  the  system. 


Figure  4-5,  Wan  Example  3 


In  the  Node  picture.  Figure  4-6,  Node  Example  3,  we  now  see  that,  although  the  PSN 
is  co-locaied  with  the  NTF,  it  is  considered  "outside”  the  NTF.  The  meaning  of  this  is 
that,  for  security  planning  purposes,  the  entire  PSN  is  outside  the  security  boundary  of  the 
NTF  (remembering  that  to  have  a  secure  PSN  one  has  to  have  a  secure  Front  End  device, 
like  Blacker  that  provides  the  needed  routing  information  as  well  as  the  encryption).  The 
other  implication  is  that,  now  all  other  nodes  of  the  NTBN  can  communicate  across  the 
PSN  without  the  NTF  being  in  the  middle.  The  plus  side  is  that  one  is  no  longer  dependent 
on  the  NTF  being  "up"  in  order  to  allow  nodes  of  the  NTBN  to  communicate.  On  the 
down  side,  there  is  now  a  "choke  point"  between  the  NTF  and  all  other  NTBN  Nodes. 

That  is,  now  there  would  only  be  a,  single,  T1  speed  line  going  into  the  NTF.  from  the 
PSN,  which  represents  its  interfaces  to  all  the  other  NTBN  Nodes  (before,  the  NTF 
connected  to  most  nodes  over  dedicated,  separate  Tl).  These,  and  any  other  pluses  and 
minuses  would  have  to  weight  carefully  before  any  decision  could  be  reached. 
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Figure  4-6,  Ncxie  Example  3 

In  the  Node  picture.  Figure  4-7,  Node  Example  4,  we  extend  the  PSN  "inside  the 
Node"  boundaty.  This  alleviates  the,  so  called,  choke  point  from  the  last  discussion,  and 
cenainly  supplies  quite  a  bit  of  security  (Type  1  encryption  between  Computer  Room  1  and 
"LAB"  for  instance).  It  also,  however,  brings  the  limited  speed  of  the  PSN  into  the  NTF. 
The  current  limit  on  the  Blacker  device  communication  speed  is  56Kb/s  (Kilobits  per 
.second).  The  suggested  speed  of  the  next  generation  Blacker  device  is  1.5  Mb/s  (Megabits 
per  second)  or  T1 .  If  the  devices  were  used  inside  a  node,  like  the  NTF,  they  would  be 
replacing  LANs  that  have  speeds  on  the  order  of  10  Mb/s.  The  tremendous  slow-down  on 
a  nodes  internal  backbone  might  not  be  an  acceptable  alternative,  especially  when  secure 
LAN  products  are  available. 


Secure  Network 


A  secure  host  (computer)  was  generally  not  identified  (although  a  couple  of  hosts  in 
Computer  Room  I  were  shown  with  an  asterisk  in  them  to  denote  the  presence  of  some 
security  boundary/feature)  in  any  of  the  architectural  pictures.  This  in  not  to  suggest  that 
secure  operating  systems  are  not  currently  available  (they  are,  for  certain  computers).  It  is 
rather  that  the  operating  systems  that  do  include  security  feature  now,  and  that  have  been 
fully  evaluated  by  the  NCSC,  are  generally  not  as  good  as  their  non-secure  counter-pans. 
This  is  changing  almost  daily,  so  there  is  reason  to  believe  that  the  NTBN  will  be  able  to 
have  such  hosts,  but  they  will  be  be  the  exception  rather  than  the  rule  for  several  years 
(where  ever  secure  versions  of  operating  systems  are  available,  it  is  suggested  that  they  are 
used  to  the  greatest  extent  possible,  shon  of  making  the  mission  fail  by  requiring  their  use). 
A  good  first  use  of  a  host  with  a  secure  operating  system  would  be  to  allow  an  unclassified 
E-mail  service,  resident  in  Computer  Room  1,  but  servicing  both  unclassified  LANs  and 
the  classified  LAN  (rules  and  administrative  oversight  would  have  to  be  established,  but 
this  is  possible  now). 


4.1  FUTURE 

By  future,  it  is  meant  here  as  a  system  that  can  be  implemented  somewhere  between 
five  and  ten  years  from  now.  The  architecture  can  be  any  of  the  ones  explored  in  the  Now 
Section,  but  with  the  additions  of:  faster  communications  media,  both  on  WANs  and 
LANs;  secure  operating  systems  for  most  hosts;  and  gener^  security  "glue"  p^,  that  fill 
in  where  some  host  or  network  is  not  security  compatible  with  another  like  entity. 


APPENDIX  C 


Glossary 


I.  SECURITY  TERMINOLOGY  DERNTTIONS 


A.  Audit 

1)  To  conduct  the  independent  review  and  examination  of  system  records  and 

activities. 

B .  Audit  Trail 

1)  A  set  of  ‘records  that  collectively  provide  documenta^  evidence  of 
processing  used  to  aid  in  tracing  from  original  transactions  forward  to 
related  records  and  reports,  and/or  backwards  from  records  and  reports  to 
their  component  source  transactions. 

C.  Authentication 

1 )  To  establish  the  validity  of  a  claimed  identify. 

2)  To  provide  protection  against  fraudulent  transactions  by  establishing  the 
validity  of  message,  station,  individual,  or  originator. 

D.  Data  Integrity 

1 )  The  state  that  exists  when  computeri2ed  data  is  the  same  as  that  in  the  source 
documents  and  has  not  been  exposed  to  accidental  or  malicious  alteration  or 
destruction. 

2)  'The  property  that  data  has  not  been  exposed  to  accidental  or  malicious 
alteration  or  destruction. 

E.  Discretionary  Access  Control  (DAC) 

1)  A  means  of  restricting  access  to  assets  based  on  the  identity  of  system  users 

and/or  groups  to  which  they  belong.  The  controls  are  discretionary  in  the 
sense  t^t  a  user  with  a  certain  access  pemiission  is  capable  of  passing  that 
permission  (perhaps  indirectly)  on  to  any  other  user  (unless  restrained  by 
mandatory  access  control). 

F.  Identification 

1)  A  means  of  establishing  an  AIS  users  identity  (generally,  a  link  between 
user’s  computer  account  name  and  the  actual  identity  of  the  person(s) 
authorized  use  of  the  account). 

G .  Identification  and  Authentication  (I&A) 

1 )  A  means  of  linking  Identification  and  Authentication  methods  together  to  act 

as  a  single,  security-relevant  entity  (such  as  computer  log-on  sequence  that 
requires  user's  computer  identification  and  password  to  be  given  prior  to 
providing  any  services). 

H .  Mandatory  Access  Control  (MAC) 

1)  A  means  of  restricting  access  to  assets  based  on  the  sensitivity  (as 


1. 


represented  by  a  label)  of  the  asset  and  the  formal  authorization  (i.e., 
clearance)  of  users  to  access  information  of  such  sensidvity. 


Privacy 

1 )  The  ability  of  an  individual  or  organizadon  to  control  the  collecdon,  storage, 
sharing,  and  disseminadon  of  personal  and  organizadonal  infcmoadon. 

2)  The  right  to  insist  on  adequate  security  of,  and  to  de&ie  authorized  users 
of,  informadon  or  systems. 

J.  Protecdon 

1)  The  means,  methods  and  mechanisms  used  by  a  system  (AIS  in  this  case)  to 
reduce  or  eliminate  access  to  itself  or  its  resources  by  some  outside  force 
(usually  defined  as  an  unauthorized  force). 

II.  SECURITY  TERMINOLOGY  DEFINITIONS  AS  APPLIED  TO  NTB 

These  concepts  of  security  are  included  here  for  background  information  and  to  assist  in 
understanding  some  of  the  fine  points  of  security,  as  they  may  apply  to  the  NTB. 

A.  Integrity 

The  concept  of  integrity,  as  here  addressed,  means  that  part  of  an  AIS  design  anchor 
implementadon  concerns  itself  with  protecting  informadon  in  the  AIS  from  alteradon  or  destrucdon 
by  an  agent  or  accident  This  area  is  naturally  addressed  as  part  of  security  because  the  security  of 
an  AIS  relies,  at  least  in  part,  on  proper  labelling  of  information  and  noncontainination  of 
information,  frtegrity  as  used  here,  however,  goes  beyond  what  might  seem  the  security  concern. 
It  also  addresses  issues  such  as  the  believability  of  informadon  derived  from  the  computations, 
consistency  of  data  bases,  correct  information  transfers  across  networks,  and  protection  of  all 
system  information  from  corruptions.  The  Trusted  Network  Interpretation  (of  the  Trusted 
Computer  Security  Evaluation  ^teria,  or  TCSEC)  (TNI)  suggests  that  along  with  a  Secrecy 
Policy,  some  systems  will  need  an  Integrity  Policy.  The  NTB  is  certainly  one  of  those  systems. 

B.  T&A  Beyond  Passwords 

Password-based  authentication  systems  are  vulnerable  to  a  variety  of  attacks  during 
the  life  of  the  passwords  such  as  those  associated  with  the  password  distribution,  selection, 
duration,  and  length.  Exploiting  the  vulnerabilities  in  the  password  system  can  result  in 
unauthorized  system  access.  The  user  identification  and  authentication  (I&A)  system  for  the  NTB 
should  be  in  addition  to,  or  a  replacement  for  the  standard  password  mechanism  afforded  by  most 
existing  operation  systems.  Passwords  themselves  are  open  to  several  known  flaws  (e.g.,  being 
written  down,  being  easily  guessed,  wire-tapping).  A  system  that  either  replaces  passwords,  or 
augments  them  can  strengthen  user  authentication  and  identification.  Alternative  A&I  techmques 
could  range  from  biometric  systems,  to  dumb  cards,  to  smart  cards,  to  cryptographic 
challengo^ly  systems. 

m.  MODES  OF  SEniRE  OPERATION 

A  mode  of  operation  in  which  the  Designated  Approval  Authority  (DAA)  accrechts  an  AIS 
to  operate.  Inherent  with  each  of  the  four  security  modes  (dedicated,  system  high,  multilevel,  and 
partitioned)  are  restrictions  on  the  user  clearance  levels,  formal  access  requirements,  need-to-know 
requirements,  and  the  range  of  sensitive  information  permitted  on  the  AIS. 


A.  Dedicated  Security  Mode 


A  mode  of  operation  wherein  all  users  have  the  clearance  or  authorization  and  need- 
to-know  for  all  data  handled  by  the  AIS.  If  the  AIS  processes  special  access  information,  aU  users 
require  formal  access  approvaL  In  the  dedicated  mc^e,  an  AIS  may  handle  a  single  classification 
level  and/or  category  of  information  or  a  range  of  classification  levels  and/or  categories. 

B.  System  High  Security  Mode 

A  mode  of  operation  wherein  all  users  having  access  to  the  AIS  possess  a  security 
clearance  or  authorization,  but  not  necessarily  a  need-to-know,  for  all  data  handled  by  the  AIS.  If 
the  AIS  processes  special  access  information,  all  users  must  have  formal  access  approvaL 

C.  Partitioned  Security  Mode 

A  mode  of  operation  wherein  all  personnel  have  the  clearance,  but  not  necessarily 
formal  access  approval  and  need-to-know,  for  all  information  handled  by  the  AIS.  This  security 
mode  encompasses  the  compartmented  mode  define  in  DCID  No.  1/16,  reference  (g). 

D.  Multilevel  Security  Mode 

A  mode  of  operation  that  allows  two  or  more  classification  levels  of  information  to 
be  processed  simultaneously  within  the  same  system  when  not  all  users  have  a  clearance  or  formal 
access  approval  for  all  data  handled  by  the  AIS. 

IV.  SUMMARY  OF  EVALUATION  CRITERIA  CLASSES 

The  classes  of  systems  recognized  under  the  trusted  computo’  system  evaluation  criteria  are 
as  follows.  They  are  presented  in  the  order  of  increasing  desirability  from  a  computer  security 
point  of  view. 

A.  gassfP^:  Minimal  Protection 

This  class  is  reserved  for  those  systems  that  have  been  evaluated  but  that  fail  to 
meet  the  requirements  for  a  higher  evaluation  class. 

B.  Gass  (CD:  Discretionary  Security  Protection 

The  trusted  Computing  Base  (TCB)  of  a  class  (Cl)  system  nominally  satisfies  the 
discretionary  security  requirements  by  providing  separation  of  users  and  data.  It  incorporates 
some  form  of  credible  controls  capable  of  enforcing  access  limitations  on  an  individual  basis,  i.e., 
ostensibly  suitable  for  allowing  users  to  be  able  to  protect  project  or  private  information  and  to 
keep  others  users  from  accidentally  reading  or  destroying  their  data.  The  class  (Cl)  environment  is 
expected  to  be  one  of  cooperating  users  processing  data  at  the  same  level(s)  of  sensitivity. 

C.  aass(C2):  Controlled  Access  Protection 

Systems  in  this  class  enforce  a  more  finely  grained  discretionary  access  control  than 
(Cl)  systems,  making  users  individually  accountable  for  their  actions  through  log-in  procedures, 
auditing  of  security-relevant  events,  and  resource  isolation. 


D.  Qass  (B 1 ):  Labeled  Security  Protection 


Qass  (61)  systems  require  all  the  features  required  for  class  {C2).  In  addidon,  an 
informal  statement  of  the  security  policy  model,  data  labeling,  and  mandatory  access  control  over 
named  subjects  and  objects  must  be  present  The  capability  must  exist  for  accurately  ladling 
exported  infbrmadon.  Any  flaws  identified  by  testing  must  be  removed. 

E.  gass(B2>:  Structured  Protection 

In  class  (B2)  systems,  the  TCB  is  based  on  a  clearly  deBned  and  documented 
formal  security  policy  model  that  requires  the  discretiona^  and  mandatory  access  control 
enforcement  found  in  class  (61)  systems  be  extended  to  all  subject  and  objects  in  the  ADP  systeni 
In  addition,  covert  channels  are  addressed.  The  T<26  must  be  carefully  structured  into  protection- 
critical  and  non-protection-critical  elements.  The  TC6  interface  is  well-defined  and  the  TC6 
design  and  implementation  enable  it  to  be  subjected  to  more  thorough  testing  and  more  complete 
review.  Authentication  mechanisms  are  strengthened,  trusted  facility  management  is  provided  in 
the  form  of  support  for  system  administrator  and  operator  functions,  and  stringent  configuration 
management  controls  are  in^sed.  The  system  is  relatively  resistant  to  penetration. 

F.  qass  (63):  Security  Domains 

The  class  (63)  TCB  must  satisfy  the  reference  monitor  requirements  that  it  mediate 
all  accesses  of  subjects  to  objects,  be  tamperproof,  and  be  small  enough  to  be  subjected  to  analysis 
and  tests.  To  this  end,  the  TC6  is  structured  to  exclude  code  not  essential  to  security  policy 
wiforcement,  with  significant  system  engineering  during  TC6  design  and  implementation  dnected 
toward  minimizing  its  complexity.  A  security  administrator  is  supported,  audit  mechanisms  are 
expanded  to  signal  security-relevant  events,  and  system  recovery  procedures  are  required.  The 
system  is  highly  resistant  to  penetration. 

G.  Class, (AD;  Ygrifi6d.I>£sisn 

Systems  in  class  (Al)  are  functionally  equivalent  to  those  in  class  (63)  in  that  no 
additional  architectural  features  or  policy  requirements  are  added.  The  distinguishing  feature  of 
systems  in  this  class  is  the  analysis  derived  from  formal  design  specification  and  verification 
techniques  and  the  resulting  high  degree  of  assurance  that  the  TC3  is  correctly  implemented  This 
assurance  is  developmental  in  nature,  starting  with  a  formal  model  of  the  security  policy  and  a 
formal  top-level  specification  (FTLS)  of  the  design.  In  keeping  with  the  extensive  design  and 
development  analysis  of  the  T(26  required  of  systems  in  class  (Al),  more  stringent  configuration 
management  is  required  and  procedures  are  established  for  securely  distributing  the  system  to  sites. 
A  system  security  administrator  is  supported. 
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1. 


INTRODUCTION 


The  consolidated  data  in  this  annex  shows  a  large  concentration  of  NTBN  user 
requirements  originating  fix)m  the  Strategic  Defense  Depute  (SD),  and  a  r^upment  for  over  40  T1 
communications  links.  As  these  data  are  validated,  and  as  the  Theater  Mission  Defense  (TD)  user 
requirements  are  defined,  however,  both  the  size  and  origin  of  the  NTBN  user  requirements  could 
change  significantly.  Thus  it  is  essential  that  the  NTBN  have  a  modular  architecture  to  allow  for 
modSar  growth. 

This  annex  includes  the  following  appendices: 

Appendix 

A  Tabulated  Requirements  Data:  This  is  a  consolidated  picture  of  NTB 

requirements  which  provides  useful  insight  into  the  NTBN  architecture 
requirements. 

B  NTB  User  Requirements:  This  chart  shows  detailed  requirements  by  user 

organization,  sponsor,  sponsor  organization,  contract  code,  type,  function, 
user  type,  node/data  rate,  and  security  classification. 

C  USASDC  User  Requirements:  This  chart  shows  test  concepts/functions  by 

USASDC  PMAS  participants  with  their  security  classification, 
communications  requirements  and  remarks. 

D  SEIC  Top  Level  User  Requirements:  This  appendix  includes  the  detailed 

surveys  developed  April  5, 1991  as  part  of  the  NTBN  effort. 

E  Requirements  Database  Sample:  TWs  appendix  presents  sample  user 

requirements  by  office  (e.g.,  L^us,  Mitre- Arlington). 

F  High  Level  User  View:  This  appendix  includes  notes  developed  diuing  the 

Technology  Group  organization^  meeting  held  April  9, 1991. 


APPENDIX  A 


Tabulated  Requirements  Data 


CONSOLIDATED  REQUIREMENTS  AND  CQNCLUSmS 


The  consolidated  NTB  requirements  data  provide  a  very  useful  picture  of  NTBN 
architecture  requirements,  although  complete  data  were  not  available  for  each  function  and  NTF 
category.  Of  the  124  NTB  User  Requirements  included,  28  showed  planned  future  requirements, 
both  internal  and  external.  Of  the  nine  SEIC  communications  requirements  identified,  four  present 
future  needs.  There  are  31 USASDC  requirements,  of  which  nine  represent  strictly  future  needs, 
w^e  five  have  differing  current  and  future  communications  requirements.  These  dieting  current 
and  future  requirements  clearly  illustrate  the  need  for  a  flexible  NTBN  architecture,  and  reinforce 
the  importance  of  maintaining  the  requirements  database  throughout  the  evolution  of  the  SDL  The 
following  paragraphs  describe  the  tabulated  data  which  are  provided  in  Tables  1-4.  The  tabulated 
data  inclucb  both  current  and  future  requirements. 

I.  Sponsor  Organization 

As  described  in  Section  HA,  the  NTBJPO  user  data  collected  by  the  Requirements 
Team  listed  sponsoring  organizations  under  the  pre-reorganization  of  SDIO.  For  SDIO  sponsored 
functions,  the  new  sponsoring  organization  was  determined  through  the  SDIO  Point  of  Contact 
(sponsor).  It  was  assumed  that  the  functions  followed  their  SDIO  sponsors  to  new  offices,  so  new 
office  symbols  were  assigned  accordingly.  For  non-SDIO  programs  (i.e.  programs  sponsored  by 
Executing  Agents  (EAs)),  the  Team  referred  back  to  PMAs  via  the  function,  and  determined  the 
SDIO  sponsor  fi-om  the  PMA.  Since  the  PMAs  also  still  show  pre-reorganization  office  symbols, 
the  SDIO  Point  of  Contact  on  the  PMA  was  again  the  key  to  assigning  an  SDIO  sponsor 
organization  to  that  function.  TTiis  latter  approach  was  also  used  to  assign  SDIO  Sponsor 
organizations  to  the  SEIC  and  USASDC  data. 

Table  1  presents  the  tabulated  data.  Out  of  the  164  functions  listed,  101,  or  61 
percent  fall  under  SD,  Deputy  for  Sttategic  Defense,  and  38,  or  23  percent  fall  under  TN,  Deputy 
for  Technology.  Thus,  86  percent  of  the  identified  NTBN  test  requirements  originate  from  these 
two  deputates. 


One  can  conclude  from  these  statistics  that  the  bulk  of  current  and  near-term  future 
requirements  for  NTBN  communications  derive  from  Strategic  Defense  and  Technology  programs 
and  in  large  part  from  Strategic  Defense  alone.  It  is  also  significant  that  none  of  the  identified 
requirements  derives  from  the  Global  Defense  System  (SDG).  This  implies  that  strategic  and 
technical  test  requirements  are  more  clearly  defined  at  present  than  are  global  (Brilliant  Pebbles)  and 
Theater  Missile  Defense  (TN©)  test  needs.  It  further  indicates  that  the  NTBN  architecture  must  be 
designed  to  accommodate  these  requirements  as  they  develop. 

II.  U.£6r.TM?s 

The  NTB  User  Requirements  List  identifies  three  user  ^es.  Type  1  is 
Administrative/Data  Exchange;  T>ye  2  is  Model  Development/Batch  Simulations;  and  Type  3  is 
Interactive,  Distributive,  or  Re^-Time  Simulations/Experiments.  The  user  type  is  a  critical  factor 
influencing  NTBN  architecture  since  it  reflects  the  probable  criticality,  amount,  and  duration  of 
traffic. 


Functions  may  involve  one  or  more  user  type.  Neither  the  SEIC  nor  the  SDC  data 
specified  user  type,  so  these  were  assumed  by  referring  functions  back  to  SDIO  PMAs  in 
conjunction  with  other  pertinent  information  such  as  user  organization.  Table  2  shows  the 
breakdown  of  user  type.  Of  147  functions,  77,  or  52  percent  involve  both  Type  1  and  2,  md  32, 
or  22  percent  require  all  three  user  types.  Thus,  the  vast  majority  of  NTB  users  have  combined  or 
varying  requirements.  Well  over  h^  of  users  have  no  requirement  for  interactive  or  real-time 


TABLE  2.  USER  TYPE  SORT 


processing  (Type  3).  This  factor  is  in^ortant  to  the  NTBN  architecture  because  Type  3  users  have 
the  most  resource  intensive  requirement 

m.  Security  aassificatinn 

Functional  network  security  classification  is  obviously  critical  to  the  NTBN 
architecture  development.  Not  all  NTB  User  Requirements  functions  specified  security 
requirements,  however  all  SEIC  and  SDC  functions  identified  communications  security  needs. 
Table  3  shows  the  compilation  of  security  requirements.  Of  the  142  functions  identified  as  having 
security  requirements,  103,  or  72  percent  required  Unclassified  to  Secret  or  Secret.  Further,  26 
functions,  or  17  percent,  have  security  requirements  beyond  the  Secret  level.  These  data  validate 
the  view  that  the  NTBN  architecture  must  support  a  Multilevel  Secure  (MLS)  mode  of  operation. 

IV.  Data  Rate 

The  data  rate  requirements  were  the  most  difficult  to  correlate.  Table  4a  shows  the 
numerical  data  as  pailable  for  NTB  User  and  USASDC  communications  needs.  Table  4b  shows 
SEIC  commmcations  data  types.  Of  the  79  functions  providing  numerical  requirements,  46,  or  58 
percent  reqi^  a  data  rate  of  Tl.  Tables  4a  and  b  iUustrate  very  clearly  the  wide  variation  in 
communications  requirements  for  the  NTBN,  Taken  together  with  the  raw  data  presented  in  the 
appendices,  these  requirements  lead  to  the  conclusion  that  the  data  capacities  must  be  flexible  as 
requirements  vary  from  one  function  to  another  and  also  vary  between  phases  of  a  particular 
function.  Only  five  ^al-up  requirements  were  identified,  which  indicates  that  the  communications 
needs  are  less  transient  in  nature  than  may  have  previously  been  supposed.  The  raw  data  also 
show  no  correlation  between  user  type  and  required  data  rate  as  might  have  been  expected. 


TABLES.  SECURITY  CLASS  SORT 
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OOM^REQSORT 


TABLE  4A.  COM  REQ  SORT  (ALL  DATA,  UNLESS  OTHERWISE  NOTED) 
I  \  USASDC  I  mAs  I 

DATA  RATE  NTBJPO  DATA  #DATAA^OICE  TOTAL 
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NTF  User  Requirements 
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APPENDIX  D 


SEIC  Top  Level  User  Requirements 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 

April  5,  1991 

_ _  J.  Swift/H.  TILLEY 


TEST  CONCEPT:  DemVal  Test  Plans 

(jTC 

<^(^\o{Pr  - 


FUNCTIONS:  Intra-element,  Inter-element  and  Integrated  System  Level  Test 


TYPES  OF  INFORMATION 
TRANSFER 

AND  GROSS  SIZING:  Real  time  Inter-element  voice,  data  &  Imagery 


TYPES  OF  SECURITY 

CLASSIFICATION  REQUIRED:  SECRETTOP  SECRET.  SAR.  SCI 


USER  COMMUNITY:  Services,  element  project  offices  element  contractors,  NTF 


TIME  PHASING.  least  two  years  before  anything  more  than  existing  NTBN 
capability  is  required 


SHoi 


TEST  CONCEPT: 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 

April  5,  1991 
J.  Swift/M.  Foti 


FUNCTIONS:  System  Operational  Effectiveness 
Element  Interactions 
Message  Profiles/Loading/Timing 
Sensor  Tasking 
Engagement  Planning 


TYPES  OF  INFORMATION 
TRANSFER 

AND  GROSS  SIZING:  Data,  imagery,  interactive  interface 


TYPES  OF  SECURITY 
CUSSIRCATTON  REQUIRED: 


SECRET,  WNINTEL 

T/S  if  Survivability  Enhancement  options  are  modeled  - 
GFY93  (TBR) 


Proprietary  (eg.  Competing  BP  contractors) 


USER  COMMUNITY:  SEIC,  NTBIC,  SDIO,  Element  Project  Offices,  Element  Con¬ 


tractors  and  SETAs,  AF-SSD,  USASDC.  AF-ESD 


TIME  PHASING; 


Development  beginning  summer  1991 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 


April  5.  1991 
J.  Swift/J.  Jewitt 


TEST  CONCEPT:  System  Communications  Security  requirement  definition 


L:fCc{  Z. 

T  . 


FUNCTIONS:  Define  System  COMSEC  requirements 


(j6er;;U^ 


TYPES  OF  INFORMATION 
TRANSFER 

AND  GROSS  SIZING:  Documentation 


TYPES  OF  SECURITY 

CUSSIFICATHDN  REQUIRED:  SECRET  and  TOP  SECRET  COMSEC 


USER  COMMUNITY:  SEIC,  SDIO,  NSA 


TIME  PHASING: 


SECRET  COMSEC  40  GFY91 
TOP  SECRET  in  GFY92 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 

April  5,  1991 

J.  Swift/E.  Mahon 


mm 


TEST  CONCEPT:  Mission  T^alysis 

5010/ pT I 

^OA 


FUNCTIONS:  "Rireat  analysis  and  definition 
Survivability  analysis 


TYPES  OF  INFORMATION 
TRANSFER 

AND  GROSS  SIZING:  Data  (Threat) 


TYPES  OF  SECURITY 

CLASSIFICATtoN  REQUIRED:  SECRET,  WNINTEL.  SAR  T/S  &  SECRET  Condor  Nest 


USER  COMMUNITY:  SEIC  &  Threat  WG 

SAIC/Huntsvilie 

SSD  Processing  Center/Survivability  Analysis  Lab 


532o7l 

1,^ 


TIME  PHASING: 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 


April  5.  1991 
J.  Swift/C.  Beatty 


TEST  CONCEPT;  Level  1  System  Simulator 


1Cio/c-vS  ('5 ‘Jo  5 


r'TMe^- 


>1^ 


FUNCTIONS;  System  Operational  Effectiveness  ^ 
Engagement  Planning  Scenarios 
Sensor  Tasking  Scenarios 
Message  Profiles/Loading/Timing  Req’ts 


TYPES  OF  INFORMATION 
TRANSFER 

AND  GROSS  SIZING;  Data,  imagery,  interactive  interface 


TYPES  OF  SECURITY 

CLASSIFICATION  REQUIRED;  SECRET,  WNINTEL 


USER  COMMUNITY;  SEIC.  NTBIC,  SDIO,  SDC,  SSD 


TIME  PHASING;  Immediate  and  continuing 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 


April  5. 1991 
J.  SwWR.  Marsden 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SEIC 


TEST  CONCEPT;  Communications  Network  Testbed 


51405: 

Can  A 


April  5.  1991 
J.  Swift/S.  Kaltnecker 


FUNCTIONS:  Message  profiles,  message  receipt  probability 
•  Link  connectivity,  routing  constraints 

Human  in  control  network  management  performance 
Data  flow  latency  and  loading 


TYPES  OF  INFORMATION 
TRANSFER 

AND  GROSS  SIZING;  Real  time  voice  &  data 

Possibly  imagery 


TYPES  OF  SECURITY 

CLASSIFICATION  REQUIRED:  SECRET,  WNINTEL 


USER  COMMUNITY;  SEIC,  NTBIC,  SDIO,  USSPACECOM 


TIME  PHASING;  GFY92  CPfJrJ£,CT\\/^  IhJlD 


- 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FOR  THE  SBC 


April  5. 1991 
J.  Swift/B.  JAMES 


NTB  COMMUNICATIONS  AND  SECURITY  ARCHITECTURE 

TIGER  TEAM  ;  '  - 

COMMUNICATIONS  REQUIREMENTS  SURVEY  FORTHESEIC 
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Requirements  Database  San^le 


REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


OFFICE: 

USER  ORGANIZATION:  LOCUS,  INC. 

SDIO  SPONSOR:  NELSON  HEAD 
CONTRACT  NUMBER:  PMA-W2300 
FUNCTION  TYPE:  O 

SDS  FUNCTION:  NRL  COMPUTER  NETWORKING  SUPPORT 
USER  TYPE:  0 
CURRENT  NODE:  LAN 
CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


)FFICE: 

USER  ORGANIZATION:  MITRE-ARLINGTON 
SDIO  SPONSOR: 

CONTRACT  NUMBER: 

FUNCTION  TYPE:  O 

SDS  FUNCTION:  MITRE  SDIO  LIASON  LONG  RANGE  PLANNING 
USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL; 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


FFICE: 

USER  ORGANIZATION;  BRILLIANT  PEEBLES  TASK  FORCE 
SDIO  SPONSOR: 

CONTRACT  NUMBER :  GOV ' T  AGENCY 
FUNCTION  TYPE:  B 
SDS  FUNCTION: 

USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE ; 

LOWEST  SECURITY  LEVEL; 

HIGHEST  SECURITY  LEVEL: 


REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


EFICE: 

USER  ORGANIZATION:  US/UK 
SDIO  SPONSOR: 

:ONTRACT  NUMBER;  GOV'T  AGENCY 
FUNCTION  TYPE:  S 
SDS  FUNCTION: 

USER  TYPE; 

CURRENT  NODE: 

CURRENT  DATA  RATE : 


OFFICE : 

USER  ORGANIZATION:  BLUE  FORCES 
SDIO  SPONSOR: 

CONTRACT  NUMBER:  GOV'T  AGENCY 
FUNCTION  TYPE:  S 
SDS  FUNCTION: 

USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE; 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 

OFFICE: 

USER  ORGANIZATION:  INNOVATIVE  SCIENCE  AND  TECH. 
<  SDIO  SPONSOR: 

CONTRACT  NUMBER:  GOV’T  AGENCY 
FUNCTION  TYPE:  T 
SDS  FUNCTION: 

USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


)!•  X'  ICE : 

USER  ORGANIZATION:  MS 
SDIO  SPONSOR: 

CONTRACT  NUMBER:  GOV'T  AGENCY 
FUNCTION  TYPE:  T 
SDS  FUNCTION: 

USER  TYPE : 

CURRENT  NODE: 

CURRENT  DATA  RATE ; 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


'FFICE: 

USER  ORGANIZATION:  COE 
SDIO  SPONSOR: 

CONTRACT  NUMBER:  GOV'T  AGENCY 
FUNCTION  TYPE:  B 
SDS  FUNCTION: 

USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 


REPORT  OF  USER  REQUIRE.MENTS  FY  IFF!  IE 


irUJNUi  iUW  i.  X  rt ;  O 

SDS  FUNCTION:  TEST  AND  EVALUATION  ACTIVITY  SUMMARY 

USER  TYPE:  1 

CURRENT  NODE:  SDIO 

CURRENT  DATA  RATE:  Tl 

LOWEST  SECURITY  LEVEL:  SECRET 

HIGHEST  SECURITY  LEVEL:  SECRET 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


‘FFICE;  AQ 

USER  ORGANIZATION:  SAIC 
SDIO  SPONSOR:  LCOL . SKVARANINA 
f  CONTRACT  NUMBER;  SDIO-84-88-C-0017 
FUNCTION  TYPE:  B 
SDS  FUNCTION: 

USER  TYPE: 

,  CURRENT  NODE : 

CURRENT  DATA  RATE : 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


FFICE:  AQ 

USER  ORGANIZATION:  NICHOLS  RESEARCH 
SDIO  SPONSOR:  LCOL . SKVARNINA 
CONTRACT  NUMBER:  SDIO-84-8S-C-0017 
FUNCTION  TYPE: 

SDS  FUNCTION: 

USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL; 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


'FICE':  AO 

USER  ORGANIZATION:  ANALYTIC  SERVICES 
SDIO  SPONSOR:  ON  USER  SUUPORT 
CONTRACT  NUMBER:  NA 
FUNCTION  TYPE:  S 

SDS  FUNCTION:  SYSTEM  ANALYSIS  (SODSIM) 

USER  TYPE:  2 
CURRENT  NODE:  SDIO 
CURRENT  DATA  RATE ; 

LOWEST  SECURITY  LEVEL;  NA 
HIGHEST  SECURITY  LEVEL:  NA 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


'x  .E :  AQ 

USER  ORGANIZATION:  BLIME.INC. 

SDIO  SPONSOR:  LTCOL  SKVARNANINA 
CONTRACT  NUMBER:  SDIO-34-S8-0-.'10~^ 
FUNCTION  TYPE:  S 

SDS  FUNCTION :  SODSIM  DEVELOPMENT  SVS 


nj.vjn£»iDi.  A  i. 


REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


'FFICE:  AQ 

USER  ORGANIZATION:  BDW  INTERN 'L  (SUPER  SETA) 
SDIO  SPONSOR:  LTCOL  SKVARNANINA 
CONTRACT  NUMBER:  SDIO-84-88-C-0017 
FUNCTION  TYPE:  O 

SDS  FUNCTION:  GPALS  STUDIES/USER  SURVEYS 
USER  TYPE: 

CURRENT  NODE: 

CURRENT  DATA  RATE: 

^  LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


FFICE:  AO 

USER  ORGANIZATION:  COLEMAN  RESEARCH  CORP . 

SDIO  SPONSOR:  LTCOL  SKVARNANINA 
CONTRACT  NUMBER:  SDIO-84-88-C-0017 
FUNCTION  TYPE: 

SDS  FUNCTION: 

USER  TYPE:  2 
CURRENT  NODE: 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


FFICE:  AQ 

USER  ORGANIZATION:  W.J.  SHAFER  ASSOC . 

SDIO  SPONSOR:  LCOL.  SKAVARNINA 
CONTRACT  NUMBER:  SDIO-84-88-C-0017 
FUNCTION  TYPE: 

SDS  FUNCTION: 

USER  TYPE : 

CURRENT  NODE: 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


'FICE:  AQ 

USER  ORGANIZATION:  BDM  INTERNATIONAL 

SDIO  SPONSOR:  LTCOL.  SKVARENINA 

CONTRACT  NUMBER:  SDIO-84-8e-C-0017 

FUNCTION  TYPE:  S 

SDS  FUNCTION:  SODSIM  EVALUATION 

JSER  TYPE:  2 

CURRENT  NODE:  SDIO 

CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL;  UNCLASS 
HIGHEST  SECURITY  LEVEL:  SECrSZ 


SDIO  SPONSOR:  BILLY  LOVE 
CONTRACT  NUMBER:  SDIO-84-e8-C-0019 
FUNCTION  TYPE:  O 

SDS  FUNCTION:  PLANNING  AND  CONTROL 
USER  TYPE:  1 
■CURRENT  NODE:  SDIO 
CURRENT  DATA  RATE: 

LOWEST  SECURITY  LEVEL: 

HIGHEST  SECURITY  LEVEL: 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


•I*  ICE:  POE 

USER  ORGANIZATION:  APPLIED  RESEARCH-ARLINGTON 
SDIO  SPONSOR:  JAMES  DRYDEN 
CONTRACT  NUMBER:  SDIO-84-88-C-0018 
FUNCTION  TYPE:  S 

*  SDS  FUNCTION:  ARCHITECTURE  ANALYSIS 
USER  TYPE:  2 
CURRENT  NODE:  SDIO 
CURRENT  DATA  RATE : 

LOWEST  SECURITY  LEVEL:  SECRET 
HIGHEST  SECURITY  LEVEL:  SECRET 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


FICE:  POE 

USER  ORGANIZATION:  DECISION  SCIENCE  APPLIC. 

DIO  SPONSOR:  JAMES  DRYDEN 
CONTRACT  NUMBER:  SDIO-84-88-C-0018 
FUNCTION  TYPE:  S 

SDS  FUNCTION:  EFFECTIVENESS  MODELS  (SODSIM) 

USER  TYPE:  2 
CURRENT  NODE:  SDIO 
CURRENT  DATA  RATE:  DIAL  UP 
LOWEST  SECURITY  LEVEL:  SECRET 
HIGHEST  SECURITY  LEVEL:  SECRET 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


FICE:  POE 

USER  ORGANIZATION:  SRS  TECHNOLOGIES-ARLINGTON 
SDIO  SPONSOR : 

CONTRACT  NUMBER:  SDIO-84-88-C-0019 
FUNCTION  TYPE:  S 

SDS  FUNCTION:  MEM  SODSIM  ANALYSIS 
USER  TYPE:  2 
CURRENT  NODE;  SDIO 
CURRENT  DATA  RATE:  TI 

LOWEST  SECURITY  LEVEL;  SECRET/NOF/CNWDI/WNINTEL 
HIGHEST  SECURITY  LEVEL:  SECRET/NOF/CNWDI/WNINTEL 

REPORT  OF  USER  REQUIREMENTS  BY  OFFICE 


'ICE :  POE 

USER  ORGANIZATION:  TASC-ARLINGTON !' SUFERSETA  : 
SDIO  SPONSOR ;  JAMES  DRYDEN 
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ANNEX  2 
TECHNOLOGffiS 
May  10,  1991 


TIGER  TEAM  REVIEW  COPY 


L  INTRODUCTION 


The  puipose  of  this  annex  is  to  assemble  and  organize  information  which  ^  assist  the 
NTBN  Security  and  Communications  Architecmre  Working  Group  (Tiger  Team)  in  developing 
architectures  which  meet  NTBN  system  requirements.  This  annex  was  prepared  by  a  Technology 
Group  working  as  an  integral  part  of  the  Tiger  Team,  whose  overall  goal  is  to  prepare  near-term 
and  long-term  recommendations  for  upgrading  NTBN  security  and  communications  capabilities. 
In  support  of  this  goal,  the  Technology  Group’s  objectives  were  defined  as  follows: 

1)  To  document  the  baseline  NTBN  configuration; 

2)  To  review  technology  documentation  previously  distributed  to  Tiger  Team  members; 

3)  To  collect  additional  informaticm  on  products  and  technologies  with  potential  application 
to  NTBN  upgrades; 

4)  To  prepare  summary  tables  and  graphics  which  would  assist  Tiger  Team  members  in 
relating  the  technology  information  to  NTBN  requirements;  and 

5)  To  write  a  final  report  for  review  by  Tiger  Team  members  in  preparation  for  subsequent 
Tiger  Team  meetings. 

The  group's  work  focused  on  LAN  and  WAN  technologies,  not  products  such  as  trusted 
operating  systems,  compartmented  mode  workstations,  DBMSs  or  access  control  subsystems 
which  enhance  the  security  of  the  individual  hosts  interconnected  by  LANs  and  WANs. 

n.  METHODOLOGY 

Technology  Group  members  held  an  organizational  meeting  on  April  9,  1991.  At  this 
meeting  and  in  subsequent  VTCYtelephone  discussions,  members  agreed  on  an  approach  to 
accomplishing  the  group’s  five  objectives.  This  approach  included  the  following  tasks: 

1)  Baseline  Architecture.  Previously  prepared  NTBN  documentation  was  analyred  to 
prepare  a  simple  set  of  diagrams  showing  the  existing  NTBN  design.  Responsibility  for  this  task 
was  assigned  to  J.  Brewer  and  P.  Burian. 

2)  Documentation  Review.  Technology  surveys  distributed  at  the  March  11-12,  1991 
Working  Group  meeting  were  reviewed  for  irtiormation  applicable  to  the  NTBN  wchitectiw 
development  effort  Responsibility  for  this  task  was  assigned  to  T.  Bailey.  The  following  specific 
documents  were  reviewed: 

a)  Target  Architecture  and  Implementation  Strategy  for  the  Joint  MLS  Technology 
Insertion  Program  ((October  10, 1990); 

b)  Secure  LAN  Product  Analysis  for  the  NTBN  (January  9, 1991); 

c)  NTB  Security  Strategy  Working  Group  Draft  Report  (March  4, 1991);  and 

d)  Security  Technology  Evaluation  Report  (NTB  Technical  Report  for  TRN 
0012-NTB-90-027  dated  October  31, 1990). 

3)  Product  and  Technology  Data  Collecti<Mi.  All  members  roUected  product  and  technology 
Hata  not  previously  presented  to  the  working  group.  Data  sources  included: 


a)  Technology  symposia  sponsored  recendy  by  NTBJPO  and  NTBIC; 

b)  The  January  1991  edition  of  NSA's  Information  Systems  Security  Products  and 
Services  Catalogue,  and  the  April  1991  Supplement  to  the  same  document. 

c)  WAN  Components  Specification,  prepared  by  NSA  Network  Project  Management 

Office; 


d)  Technical  information  obtained  directly  from  vendors;  and 

e)  Data  which  Technology  Group  members  have  access  to  through  their  participation  in 
other  secure  networking  projects. 

4)  Data  Analysis  pd  Reduction.  The  information  collected  in  steps  1, 2,  and  3  above  was 
analyzed  and  presented  in  tabular  and  graphical  formats  to  facilitate  discussions  of  alternative 
architectures.  Tables  divided  products  into  categories,  summarized  their  characteristics,  and 
compared  their  ability  to  meet  perceived  NTBN  communications  and  security  requirements. 
Graphics  showed  how  available  products  fit  into  generic  network  architectures.  Responsibility  for 
this  task  was  shared  by  J.  Brewer,  P.  Burian  and  T.  Bailey. 

5)  Final  Report.  Results  of  the  Technolo^  Group's  efforts  were  collected  in  this  report. 
The  detailed  results  are  provided  as  a  set  of  t^penffices.  A  brief  summary  is  given  in  the  following 
paragraph. 

m.  SUMMARY  OF  RESULTS 

The  following  appendices  to  this  report  are  provided  to  the  Security  and  Communications 
Architecture  Working  Group  as  tools  to  facilitate  development  of  near-term  and  long-term  NTBN 
architectures: 

p  Appendix  A— Baseline  Architecture  Diagrams.  Two  figures  are  provided.  Figure  A-1 
summarizes  the  AIS  components  and  tail  circuits  at  NTBN  nodes.  Figure  A-2  shows  the  existing 
wide  area  network  communications  architecture  which  interconnects  the  nodes. 

2)  Appendix  B— Evaluated  Products  List.  Material  was  extracted  fiom  the  January  1991 
Evaluated  ftoducts  List  and  annotated  to  include  EPL  changes  through  March  1,  1991  as 
documented  in  the  April  1991  EPL  supplement.  The  EPL  defines  four  classes  of  products:  1) 
Unix-like  Systems  (including  Compartmented  Mode  Workstations);  2)  Proprietary  (i.e., 
non-Unix)  Systems;  3)  Networks  and  Network  Components;  and  4)  Subsystems.  'Trusted 
database  management  systems  are  not  currently  included  (Hi  the  EPL. 

3)  Appendix  C— Secure  Networking  Product  Summary.  Information  on  networking 
products  surveyed  in  Task  2  and  Task  3  above  is  sunomarized  in  tabular  format  Table  C-1  divides 
networking  products  into  four  categories  based  on  whether  or  not  Type  1  encryption  and/or  trusted 
software  are  designed  into  the  product  Table  C-2  describes  how  each  of  these  products  is  used  in 
a  secure  LAN  or  WAN  environment  Table  C-3  compares  product  features  and  specifications 
which  are  relevant  to  the  NTBN  architecture  development  task. 

4)  Appendix  D— WAN  Product  Data.  SDIO's  NSA  representatives  furnished  this  data  on 
products  currently  in  use  in  DoD  WANs. 


5)  Appendix  E-Technology  Briefing.  This  is  a  presentation  prepared  by  the  OTB 
integration  contractor.  It  summarizes  information  presented  at  various  technology  symposiums 
sponsored  by  the  NTBJPO. 

6)  Appendix  F-Generic  Architecture  Diagrams-Graphics  showing  how  products 
described  in  Appendix  C  are  used  in  LAN  and  WAN  architectures.  These  ^grams  are  taken  from 
vendor  literature,  Government  briefings,  and  documents  analyzing  available  network  security 
products. 
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EVALUATED  PRODUCTS  LIST 


13 


'JAumAjCt'  I  "J ' 

EVALUATED  PRODUCTS  LIST 

for 

TRUSTED  COMPUTER  SYSTEMS 
As  of  1  December  1990 

iji-th  anno-i-ahon.C 
cl^aAAtfS  ‘H^r&u.ak  Ai^rcA 

prfSr^yiej^  Af>r\\  /i‘»/ 

BPL 


4-3 


INDEX  OF  EVALUATIONS  BY  PHASE 
I.  Products  In  the  Vendor  Assistance  Phase: 

Vendor 

Amdahl  Corporation 
Convex  Computer  Corp 
Harris  Corporation 
Silicon  Graphics  Inc. 

Sun  Microsystems 


Vendor 

Addamax  Corporation 


■(!c-^cr7/>u  fo 
✓ 


Concurrent  Computer  Corporation 
Digital  Equipment  Corporation 


Gemini  Computers,  Inc. 


Sun  Microsystems  Federal,  Inc. 
Tandem  Computers,  Inc. 


Page 

4-30 

ase: 

Product  Candidate  Division 

4-30 

4-30 

4-30 

4-30 

^•3o 

Page 

System  V  UNIX  System 

B 

4-32 

4.3BSD  UNIX  System 

B 

4-32 

Compartmented  Mode 

B 

4-32 

Workstation 

UNIXV 

B 

4-32 

OS-32 

C 

4-32 

Compartmented  Mode 

B 

4-32 

Workstation 

SE-VMS 

C/B 

4-32 

GEMSOS 

A 

4-32 

M-COMPONENT 

A 

4-32 

VM/SP 

C/B 

4-32 

Compartmented  Mode 

B 

4-32 

Workstation 

Guardian-90 

C 

4-32 

4-16 


III.  Products  In  Formal  Evaluation: 


Vendor 


Product 


Candidate 
Level  of  Trust 


Page 


Boeing  Aerospace 


HFSI,  Inc 
SecLirewar^nc. 


SNS 

SNS  +  NM 
XTS-200 


SecLifeware<Tnc.  /  Comparttnented  ^ 
/  /  /Workstation 

Trusted  Infown'ation  ^sterns,  Inc'' 

/  /  /  lasted  XENIX 


B3  ,  ,4-52 

^  'A'/’' 

51^  Cb'^r  4-49, 


C 


.a 


IV.  Evaluated  Systems  and  Add-On  Packages: 


Vendor 

Product 

Level  of  Trust 

Page 

American  Telephone  &  Telegraph  (AT&T) 

System  V/MLS 

B1 

4-82 

Computer  Associates  International 

ACF2/MVS 

C2 

4-104 

ACF2A/M 

C2 

4-69 

Top  Secret 

C2 

4-106 

Control  Data  Corp. 

NOS 

C2 

4-60 

Data  General  Corp. 

AOS/VS 

C2 

4-79 

Digital  Equipment  Corp. 

VAX/VMS  4.3 

C2 

4-62 

Gould,  Inc.,  Computer  Systems  Division 

UTX/32S 

C2 

4-65 

Hewlett  Packard  Computer  Systems  Div. 

MPE  V/E 

C2 

4-77 

Honeywell  Information  Systems,  Inc. 

Multics 

B2 

4-58 

SCOMP 

A1 

4-56 

4-17 


Vendor 

Product 

Level  of  Trust 

Page 

International  Business  Machines  Corp. 

MVS/RACF 

Cl 

4-102 

MVS/XA/RACF 

C2 

4-72 

VM/SP  with  RACF 

C2 

4-88 

MVS/ESA 

B1 

4-95 

i/ti+T’  J  )(c o  lie-  ■  0 

01 

,  ^'-S-20 

Prime  Computer,  Inc. 

Primes 

C2 

4-75 

i-Ja/r,  Trtt 

d'MuJ 

61 

^■5  20 

Unisys  Corp. 

A  Series 

C2 

4-67 

OS  1100 

B1 

4-85 

Verdix  Corp. 

VSLAN  5.0 

B2  MAID 

4-91 

Wang  Laboratories 

SVS/OS  CAP  1 .0 

C2 

4-99 

V.  Evaluated  Subsystems; 

ALC  Stealth  Group 

Tigersafe 

l&A/D:OR/D 

4-128 

Tigersafe  3.03.1  EN 

l&A/D:OR/D 

4-137 

Clyde  Digital  Systems 

Dialback 

Subsystem 

4-123 

Codercard,  Inc. 

CPP-300 

Subsystem 

4-111 

Computer  Accessories,  IncPrivate  Access 

Subsystem 

4-122 

Computer  Security  Corp. 

Citadel 

Subsystem 

4-124 

Sentinel 

Subsystem 

4-116 

Cortana  Systems  Corp. 

PC  Security 

Subsystem 

4-120 

Enigma  Logic,  Inc. 

Safeword 

Subsystem 

4-115 

E-X-E  Software  Inc. 

OnGuard 

l&A/D1:DAC/D1 

4-136 

Eyedentify  Inc. 

EIS 

l&A  /  D1 

4-139 

Fischer  International 

Watchdog 

Subsystem 

4-112 

Watchdog  Armor 

l&A/D1;DAC/D2: 

1-141 

AUD  /  D2;  OR  /  D 

Gordian  Systems,  Inc. 

Access  Key 

Subsystem 

4-110 

IDENTIX  Corp. 

IDX-50 

Subsystem 

4-119 

Infosafe  Corp. 

X-LOCK  50 

Subsystem 

4-125 

Infotron 

INX  4400 

l&A  /  D 

4-126 

Key  Concepts,  Inc. 

SureKey 

Subsystem 

4-118 

Micronyx,  Inc. 

Triad  Plus 

Subsystem 

4-117 

TriSpan 

l&A/D;DAC/D;AUD/D 

4-130 

Pyramid  Development  Corp. 

PC/DACS 

l&A/D;  DAC/D;  AUD/D;  OR/D  4-134 

Security  Dynamics,  Inc. 

ACE 

Subsystem 

4-114 

Spectrum  Manufacturing,  Inc. 

DPS  800/12 

Subsystem 

4-121 

Sytek,  Inc. 

PFX  Passport 

Subsystem 

4-113 

Wang  Laboratories 

MicroControl 

l&A  /  D;  DAC  /  D;  AUD  /  D 

4-132 

4-18 


INDEX  OF  Completed  AND  Formal  EVALUATIONS  BY  LEVEL  OF  TRUST 


f^iihsvstems: 


Vendor 


Product 


ALC  Stealth  Group 

Clyde  Digital  Systems 
Codercard,  Inc. 

Computer  Accessories,  Inc. 
Computer  Security  Corp. 
Computer  Security  Corp. 
Cortana  Systems  Corp. 
Enigma  Logic,  Inc. 

E-X-E  Software  Security 
Eyedentify  Inc. 

Fischer  International 

Gordian  Systems,  Inc. 
IDENTIX  Corp. 

Infosafe  Corp. 

Infotron 

Key  Concepts,  Inc. 

Micronyx,  Inc. 

Pyramid  Development  Corp. 
Security  Dynamics,  Inc. 
Spectrum  Manufacturing,  Inc. 
Sytek,  Inc. 

Wang  Laboratories 


Tigersafe 

Tigersafe  3.03.1  EN 

Dialback 

CPP-300 

Private  Access 

Citadel 

Sentinel 

PC  Security 

Safe  word 

OnGuard 

EIS 

Watchdog 
Watchdog  Armor 
Access  Key 
IDX-50 
X-LOCK  50 
INX  4400 
SureKey 
Triad  Plus 
TriSpan 
PC/DACS 
ACE 

DPS  800/12 
PFX  Passport 
Micro  Control 


on 


Vendor  Product 

International  Business  Machines  Corp. 

MVS/RACF 


Evaluation 

Status 

Completed 


QZi 


Computer  Associates 


International 
ACF2/MVS 
acf2/VM 
Top  Secret 


Completed 

Completed 

Completed 


Page 

4-128 

4-137 

4-123 

4-111 

4-122 

4-124 

4-116 

4-120 

4-115 

4-136 

4-139 

4-112 

4-141 

4-110 

4-119 

4-125 

4-126 

4-118 

4-117 

4-130 

4-134 

4-114 

4-121 

4-113 

4-132 


Page 


4-102 


4-104 

4-68 

4-106 


4-19 


QZl  (cont.) 


Vendor  Product 

Evaluation 

Status 

Page 

Control  Data  Corporation  NOS 

Completed 

4-60 

Data  General  Corp.  AOSA/S 

Completed 

4-79 

Digital  Equipment  Corporation 

VAXA/MS  4.3 

Completed 

4-62 

Gould,  Inc.,  Computer  Systems  Division 

UTX/32S 

Completed 

4-65 

Hewlett  Packard  Computer  Systems  Div. 

MPE  V/E 

Completed 

4-77 

International  Business  Machines  Corp. 


MVS/XA  with  RACF  Completed 

VM/SP  with  RACF  Completed 

4-72 

4-88 

Prime  Computer,  Inc. 

Primes 

Completed 

4-75 

Unisys  Corp. 

A  Series 

Completed 

4-65 

Wang  Laboratories,  Inc. 

SVS/OS 

Completed 

4-99 

hll 

Vendor  Product 

American  Telephone  and  Telegraph  Co. 

System  V/MLS 

Evaluation 

Status 

Completed 

Page 

4-82 

International  Business  Machines  Corp. 

MVS-ESA 

Completed 

4-95 

Secureware,  Inc. 

Compartmented 
Mode  Workstation 

^PrrtwT  fj 

C-  Orrspl-irJI 

4-49 

Unisys  Coip. 

OS  1100 

Completed 

4-85 

4-20 


Vendor 

Product 

Evaluation 

Status 

Page 

Honeywell  Information  Systems.  Inc. 

Multics' 

Completed 

4-58 

Trusted  Information  Systems,  Inc. 

Trusted  XENIX 

.Fornr^ 

4-46 

Verdix  Corp. 

VSLAN 

Completed 

4-91 

£2: 

Vendor 

Product 

Evaluation 

Status 

Page 

Honeywell  Information  Systems,  Inc 

XTS-200 

Formal 

4-52 

M: 

Vendor 

Product 

Evaluation 

Status 

Page 

Boeing  Aerospace 

SNS 

SNS  +  NM 

Formal 

4-44 

Honeywell  Information  Systems,  Inc. 

SCOMP  Completed  4-56 


4-21 


INDEX  OF,EVALUATED  PRODUCTS  AND  PRODUCTS  IN  EVALUATION  BY 

VENDOR 


Vendor 

Product/Product  Type 

Evaluation 

Status 

Page 

Addamax  Corp. 

System  V  UNIX  System 

4.3BSD  UNIX  System 
Compartmented  Mode 

Workstation 

DA 

DA 

DA 

4-32 

4-32 

4-32 

Amdahl  Corp. 

Network  Component 

UNIX  operating  system 

VAP 

VAP 

4-30 

4-30 

ALC  Stealth  Group 

Tigersafe 

Tigersafe  3.03.1  En 

Completed 

Completed 

4-128 

4-137 

American  Telephone  and  Telegraph  Co. 

System  V/MLS 

UNIX  System  V 

Completed 

DA 

4-82 

4-32 

Boeing  Aerospace 

SNS 

SNS  +  NM 

Formal 

4-44 

Clyde  Digital  Systems 

Diaiback 

Completed 

4-123 

Codercard,  Inc. 

CPP-300 

Completed 

4-111 

Computer  Accessories,  Inc. 

Private  Access 

Completed 

4-122 

Computer  Associates  International 

ACF2/MVS 

acf2A/M 

Top  Secret 

Completed 

Completed 

Completed 

4-104 

4-69 

4-106 

Computer  Security  Corp. 

Citadel 

Sentinel 

Completed 

Completed 

4-124 

4-116 

Concurrent  Computer  Corporation 

OS-32  real-time  operating  system 

DA 

4-32 

Control  Data  Corporation 

NOS 

Completed 

4-60 

Convex  Computer  Corp. 

Unix  operating  system 

VAP 

4-30 

4.22 


Evaluation 

Vendor 

ProducVProduct  Type 

Status 

Page 

Cortana  Systems  Corp. 

PC  Security 

Completed 

4-120 

Data  General  Corp 

AOSA/S 

Completed 

4-79 

Digital  Equipment  Corporation 

VAX/VMS  4.3 

Completed 

4-62 

Compartmented  Mode  Workstation 

DA 

4-32 

SE-VMS 

DA 

4-32 

Enigma  Logic.,  Inc 

Safeword 

Completed 

4-115 

E-X-E  Software  Security 

OnGuard 

Completed 

4-136 

Eyedentify  International  Systems  Corp 

Eyedentify  Information  Security 

Completed 

4-139 

System  (EIS) 

Fischer  International 

Watchdog 

Completed 

4-112 

Watchdog  Amor 

Completed 

4-141 

Gemini  Computers,  Inc. 

GEMSOS 

DA 

4-32 

M-Component 

DA 

4-32 

Gordian  Systems,  Inc. 

Access  Key 

Completed 

4-110 

Gould,  Inc.,  Computer  Systems  Division 

UTX/32S 

Completed 

4-65 

Harris  Corporation 

Unix  operating  system 

VAP 

4-30 

Hewlett  Packard  Computer  Systems  Div. 

MPE  V/E 

Completed 

4-77 

Honeywell  Information  Systems,  Inc. 

Multics 

Completed 

4-58 

SCOMP 

Completed 

4-56 

HFSI  Inc. 

XTS-200 

Formal 

4-52 

Evaluation 

Vendor 

Product/Product  Type 

Status 

Page 

International  Business  Machines  Corp 

MVS/RACF 

Completed 

4-102 

MVS/XA  with  RACF 

Completed 

4-72 

VM/SP  with  RACF 

Completed 

4-88 

MVS-ESA 

Completed 

4-95 

VM/SP 

DA 

4-32 

IDENTIX  Corp. 

IDX-50 

Completed 

4-119 

Infosafe  Corp. 

X-LOCK-50 

Completed 

4-125 

Infotron 

INX  4400 

Completed 

4-126 

Key  Concepts,  Inc. 

Sure  Key 

Completed 

4-118 

Micronyx,  Inc. 

Triad  Plus 

Completed 

4-117 

TriSpan 

Completed 

4-130 

Prime  Computer,  Inc. 

Primes 

Completed 

4-75 

Pyramid  Development  Corp. 

PC/DACS 

Completed 

4-134 

Secu reware,  Inc. 

Compartmented  Mode  Workstation 

4-49 

Security  Dynamics,  Inc. 

ACE 

Completed 

4-114 

Silicon  Graphics  Inc. 

Unix  operating  system 

VAP 

4-30 

Spectrum  Manufacturing,  Inc. 

DPS  800/12 

Completed 

4-121 

Sun  Microsystems  Federal,  Inc. 

Compartmented  Mode  Workstation 

DA 

4-32 

UNIX  based  Operating  System 

VAP 

4-30 

Sytek,  Inc. 

PFX  Passport 

Completed 

4-113 

Tandem  Computers  Inc. 

Guardian-90 

DA 

4-32 

4-24 


Evaluation 


Vendor 

Product/Product  Type 

Status 

Page 

Trusted  Information  Systems,  Inc. 

Trusted  XENIX 

C' 

JFwerai 

4-46 

Unisys  Corp. 

A  Series 

OS  1100 

Completed 

Completed 

4-67 

4-85 

Verdix  Corp. 

VSLAN 

Completed 

4-91 

Wang  Laboratories,  Inc. 

SVS/OS 

MicroControl 

Completed 

Completed 

4-99 

4-132 

4-25 


INDEX  OF  PRODUCTS  BY  TYPE 


1.  UNlX*like  Systems; 

•  Evaluation 

Vendor 

Product/Product  Type 

Status 

Page 

Addamax  Corp. 

System  V  UNIX  System 

4.3BSD  UNIX  System 

Compartmented  Mode 

DA 

DA 

DA 

4-32 

4-32 

4-32 

Workstation 

Amdahl  Corp. 

UNIX  operating  System 

VAP 

4-30 

American  Telephone  and  Telegraph  Co 

System  V/MLS 

Completed 

DA 

4-82 

4-32 

UNIX  System  V 

Convex  Computer  Corp. 

UNIX  operating  system 

VAP 

4-30 

Digital  Equipment  Corporation^^^^^^^^^^  Workstation 

DA 

4-32 

Gould,  Inc.,  Computer 

Completed 

4-65 

Harris  Corporation 

Unix-based  Operating  System 

VAP 

4-30 

HFSI,  Inc. 

XTS-200 

Formal 

4-52 

Secureware,  Inc. 

Compartmented  Mode  Workstation 

Formal 

4-49 

Silicon  Graphics  Inc. 

UNIX  operating  system 

VAP 

4-30 

sun  Microsystems  Mode  Workstation 

DA 

VAP 

4-32 

4-30 

UNIX  based  operating  system 

Trusted  Information  Systems,  Inc. 

Trusted  XENIX 

Formal 

4-46 

II.  Proprietary  Systems: 


Vendor 

Product/Product  Type 

Evaluation 

Status 

Page 

Computer  Associates  International- 

ACF2/MVS 

Completed 

4-104 

acf2/VM 

Completed 

4-69 

Top  Secret 

Completed 

4-106 

Concurrent  Computer  Corporation 

OS-32  real-time  operating  system 

DA 

4-32 

Control  Data  Corporation 

NOS 

Completed 

4-60 

Data  General  Corp 

AOSA/S 

Completed 

4-79 

Digital  Equipment  Corporation 


VAX/VMS  4.3 

Completed 

4-62 

SE-VMS 

DA 

4-32 

Gemini  Computers,  Inc.  GEMSOS 

DA 

4-32 

M-Component 

DA 

4-32 

Hewlett  Packard  Computer  Systems  Div. 

MPE  V/E 

Completed 

4-77 

Honeywell  Information  Systems,  Inc. 

Multics 

Completed 

4-58 

SCOMP 

Completed  ‘ 

4-56 

International  Business  Machines  Corp 

MVS/RACF 

Completed 

4-102 

MVS/XA  with  RACF 

Completed 

4-72 

VM/SP  with  RACF 

Completed 

4-88 

MVS-ESA/RACF 

Completed 

4-95 

VM/SP 

DA 

4-32 

Prime  Computer,  Inc.  Primes 

Completed 

4-75 

Tandem  Computers  Inc.  Guardian-90 

DA 

4-32 

Unisys  Corp.  A  Series 

Completed 

4-67 

OS  1100 

Completed 

4-85 

Vendor 

Product/Product  Type 

Evaluation 

Status 

Page 

Wang  Laboratories,  Inc. 

SVS/OS 

Completed 

4-99 

III.  Networks  and  Network  Comoonents: 

Vendor 

Product/Product  Type 

Evaluation 

Status 

Page 

Amdahl  Corp. 

Network  Component 

VAP 

4-30 

Boeing  Aerospace 

SNS 

SNS  +  NM 

Formal 

4-44 

Verdix  Corp. 

VSLAN 

Completed 

4-91 

IV.  Subsystems: 

Vendor 

Product 

Page 

ALC  Stealth  Group 
ALC  Stealth  Group 
Clyde  Digital  Systems 
Codercard,  Inc. 

Computer  Accessories,  Inc. 
Computer  Security  Corp. 
Computer  Security  Corp. 
Cortana  Systems  Corp. 
Enigma  Logic.,  Inc. 

Eyedentify  Inc. 

Fischer  International 
Fischer  International 
Gordian  Systems,  Inc. 
IDENTIX  Corp. 

Infosafe  Corp. 

Infotron 

Key  Concepts,  Inc. 

Micronyx,  Inc. 

Pyramid  Development  Corp. 
Security  Dynamics,  Inc. 
Spectrum  Manufacturing,  Inc. 
Sytek,  Inc. 

United  Software  Security 
Wang  Laboratories 


Tigersafe 

4-128 

Tigersafe  Ver  3.03.01  EN 

4-137 

Dialback 

4-123 

CPP-300 

4-111 

Private  Access 

4-122 

Citadel 

4-124 

Sentinel 

4-116 

PC  Security 

4-120 

Safeword 

4-115 

EIS 

4-139 

Watchdog 

4-112 

Watchdog  Armor 

4-141 

Access  Key 

4-110 

IDX-50 

4-119 

X-LOCK-50 

4-125 

INX  4400 

4-126 

SureKey 

4-118 

Triad  Plus 

4-117 

TriSpan 

4-130 

PC/DACS 

4-134 

ACE 

4-114 

DPS  800/12 

4-124 

PFX  Passport 

4-113 

OnGuard 

4-136 

MicroControl 

4-132 

VENDOR  ASSISTANCE  PHASE 
POTENTIAL  PRODUCTS  LIST 


I.  Trusted  Systems  and  Operating  Systems  (UNIX-like  Systems) 


Vendor 

POC&# 

Product  Description 

Amdahl  Corporation 

Bill  O’Connell 
(408)746-6891 

Unix  based  Operating  System 

Convex  Computer  Corp  Blair  Baker 

(214)497-4536 

Unix  based  Operating  System 

Harris  Corporation 

Wendell  Norton 
(305)973-5201 

Unix  based  Operating  System 

Silicon  Graphics  Inc 

Linda  Jo  Dolny 
(415)335-1021 

Unix  based  Operating  System 

TNri'^^un  Microsystems 

Rosc&rc-k 

^rryBarop.^  Unix  based^perating  ^tem 

,/T408L27^414  -  n 

.  Pc.t»|  itc-seQ  5*,  s 

a/a)  6?3-5-y67  ' 

II.  Trusted  Systems  and  Operating  Systems  (Proprietary  Systems) 

Vendor 

POC  &  # 

Product  Description 

None 

III.  Network  Systems  and  Network  Components 

Vendor 

POC  &  # 

Product  Description 

Amdahl  Corporation 

Bill  O’Connel 
(408)746-6891 

Network  Component 

Lo^&l 

^4>n't'rol 

ill*))  5'^‘i-IOlX 

VENDOR  ASSISTANCE  PHASE 
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DESIGN  ANALYSIS  PHASE 
POTENTIAL  EVALUATED  PRODUCTS  LIST 


I.  Trusted  Systems  and  Operating  Systems  (UNIX-like  Systems) 


Vendor 

POC&# 

Product  and  Candidate  Division 

Addamax  Corp. 

Randall  J.  Sandone 
(217)  359-0700 

System  V  UNIX  System  -  B 

4.3BSD  UNIX  System  -  B 
Compartmented  Mode  Workstation  -  B 

AT&T 

Jeanne  M.  Baccash 
(201)522-6028 

UNIXV-B 

Digital  Equipment 
Corporation 

Paul  T.  Cummings 
(508)  264-5026 

Compartmented  Mode  Workstation  -  B 

Sun  Microsystems 

Larry  Baron 
(408)  276-3414 

Compartmented  Mode  Workstation  -  B 

II.  Trusted  Systems  and  Operating  Systems  (Proprietary  Systems) 

Vendor 

POC&# 

Product  Description 

Concurrent 

Computer  Corporation 

Chris  J.  Kirschman,  Jr. 
(201)  758-7566 

OS-32  real-time  operating  system  -  C 

Digital  Equipment 
Corporation 

Barney  Loiter 
(301)731-3717 

Security  Enhanced  VMS  -  C/B 

Gemini  Computers  Inc. 

Dr.  Tien  F.  Tao 
(408)  373-8500 

GEMSOS-A 

M-Component  -  A 

International  Business 
Machines  Corp 

David  M.  Frayne 
(914)288-2612 

VM/SP-C/B 

Tandem  Computers  Inc. 

William  J.  Buer 
(408)  725-6000 

Guardian-90  -  C 

DESIGN  ANALYSIS  PHASE 
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SECURE  NETWORKING  PRODUCT  SUMMARY 


TABLE  C-1 .  CATEGORIES  OF  NETWORKING  PRODUCTS 
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TABLE  C-2.  SUMMARY  OF  PRODUCT  FUNCTION  AND  CERTIFICATION  STATUS 


TABLE  C-2.  SUMMARY  OF  PRODUCT  FUNCTION  AND  CERTIFICATION  STATUS  (CONT) 
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WAN  PRODUCT  DATA 
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Characteristies 


Product  History 

Models:  IDNX/10.  IDNX/20,  IDNX/40,  IDNX/70,  IDNX/ 
70T,  and  IDNX/90. 

Date  of  First  Delivery:  IDNX/40 — September  19. 1986; 
IDNX/70— October  10, 1986;  IDNX/20— December  1 , 
1987;  IDNX/10— December  1989;  IDNX/90— September 
1990:  ADNX/48 — scheduled  for  the  end  of  1990. 

Number  Installed  to  Date:  3.423  IDNX  nodes  shipped 
as  of  July  1, 1990. 


Description 

The  IDNX/10  supports  one  active  and  one  redundant  T1 
trunk.  A  single  T1  line  on  an  IDNX/10  supports  up  to  23 
voice  circuits  or  30  data  circuits. 

Each  IDNX/20  node  can  terminate  up  to  15  T1 
trunks  and  support  up  to  336  active  voice  circuits  or  84 
active  data  circuits  at  1 .2K  bps  to  1 9.2K  bps  or  56  active 
data  circuits  at  56K  bps.  The  maximum  aggregate  data 
rate  is  1.344M  bps. 

An  IDNX/40  node  can  terminate  up  to  15  T1  trunks 
and  supports  termination/origination  of  up  to  68  active 
data  circuits.  Up  to  51 2  pass-through  voice/data  circuits 
are  supported. 

An  eight-shelf  IDNX/70  node  can  terminate  up  to 
96  T1  trunks.  It  supports  up  to  1 .024  active  voice/data 
circuits  per  node,  either  on  a  demand-assigned  or  per¬ 
manent  basis. 

The  IDNX/90  supports  up  to  four  T3  connections. 
Each  T3  trunk  module  provides  connection  for  a  single 
T3  circuit. 

IDNX  features  include  preempted  priority  assign¬ 
ment;  support  for  cable,  microwave,  satellite,  and  fiber 
optic  media;  time-of-day  bandwidth  reservation: 
demand-assigned  bandwidth;  and  selectable  call  routing 
attributes,  including  terrestrial/satellite,  encrypted/ 
nonencrypted,  and  CCITT  ADPCM/N.E.T.  ADPCM/ 
ADPCM  plus  8K  bps  and  16K  bps  Vector  Adaptive 
Predictive  Coding  compression. 

Network  clocking  and  synchronization  are  accom¬ 
plished  through  a  choice  of  internal  or  up  to  eight  exter¬ 
nal  clocking  sources  with  a  fallback  priority  scheme. 

The  IDNX  internal  oscillator  meets  stratum  3  accuracy 
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criteria.  Pass-through  timing  is  supponed  when  the  net¬ 
work  IS  locked  to  a  aifferent  frequency  from  the  data 
circuit. 

The  IDNX  supports  centralized  and/or  distributed 
integral  network  control  and  management.  Capabilities 
Include  password  protection  and  operator  privilege  lev¬ 
els,  network  monitoring,  diagnostics,  and  reconfigura¬ 
tion.  Diagnostics  include  comprehensive  loopback  tests. 
Extensive  parameter  selection  is  available.  For  exam¬ 
ple.  call  processing  parameters  configurable  from  the 
operator  console  include  Maximum  Calls  on  Node 
(1,024  maximum);  Maximum  Call  Setup  Retries  (1  to  4); 
Maximum  Hops  per  Call  (1  to  12);  Maximum  Satellite 
Hops;  Call  Statistics  Reporting  interval  (1  to  1 ,440  min¬ 
utes);  Call  Detail  Recording  Enable/Disable;  Reconnect 
Timeout  (1  to  60  seconds);  Pre-empt  Control  (0  to  1 1 . 
indicating  the  maximum  number  of  hops  that  a  pre¬ 
empted  priority  call  can  take  to  reach  its  destination 
without  preempting  other  calls);  and  Number  of  Links  to 
Node. 

ADNX/48 

The  Access  Digital  Network  Exchange  (ADNX/48)  Inte¬ 
grated  Access  Managers  are  intelligent  channel  banks 
that  complement  the  IDNX  family.  The  ADNX/48  is  de¬ 
signed  for  local  applications  where  more  than  12  voice 
c  rcuits  require  connection  to  an  IDNX.  but  where  a  di¬ 
rect  digital  PBX  connection  is  unavailable.  The  ADNX/48 
also  provides  access  for  sites  that  require  connection  to 
the  public  network  for  voice  circuits  as  well  as  high¬ 
speed  access  to  a  private  backbone  network  for  LAN 
connections  or  video-  or  teleconferencing  equipment. 
The  ADNX/48  especially  complements  the  IDNX/10. 
which  is  best  used  in  small,  data-only,  remote  applica¬ 
tions. 

The  ADNX/48  is  suited  for  drop-and-lnsert  appli¬ 
cations,  multidrop  applications,  and  applications  that 
usually  would  require  two  channel  banks.  Software  con¬ 
trols  provide  configuration  and  fault  management  tools 
to  meet  the  requirements  of  remote  sites. 

The  ADNX/48  permits  flexible  configuration  op¬ 
tions.  It  can  perform  dual  T1  operations  (up  to  48  chan¬ 
nels);  single  T1  operation  (24  DSO  channels);  and 
bidirectional,  drop-and-insen  operation. 

The  following  software-programmable  voice  cards 
are  part  of  the  ADNX/48: 

•  DS1  digital  PBX  interface 

•  4-wire  E&M/PLR/TO  (Terminate  Only) 

•  2-wlre  FXS/DPT/PLAR  Megacomm 

•  2-wire  FXO/DPO 

These  cards  are  compatible  with  all  three  ADNX/48 
models. 

In  addition,  software-programmable  and 
hardware-configured  data  cards  support  synchronous 
data  rates  from  2.4K  bps  to  1.536K  bps.  Interfaces  In¬ 
clude  V.35,  RS-422.  and  RS-232-C.  An  Intelligent  DDS- 
compatible  Subrate  Data  Multiplexing  (SDM)  card 
provides  five  ports  per  card  (with  a  maximum  rate  of. 
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9.6K  bps  per  port).  An  optional  integrated  dual-port  D4/ 
ESF  Channel  Service  Unit  that  is  compatible  with  all 
three  models  is  available. 

IDNX/10 

The  IDNX/10  provides  connectivity  to  backbone  net¬ 
works  for  low-volume  sites  as  well  as  compatibility  with 
a  variety  of  carrier  services,  such  as  fractional  T1 .  The 
IDNX/10  is  DSO  channelized  and  is  fully  compatible  with 
all  other  IDNX  products  as  well  as  with  digital  cross- 
connect  systems.  This  allows  access  to  such  services 
as  AT&T  Megacom/800  and  SDN,  MCI  Prism,  and  US 
Sprint  VPN  and  Ultra  WATS.  Also,  access  to  ISDN  offer¬ 
ings  will  be  possible  as  they  become  available. 

The  IDNX/10  supports  two  T1  trunks:  one  active 
and  one  redundant.  A  T1  facility  on  an  IDNX/10  sup¬ 
ports  up  to  23  voice  circuits  or  30  data  circuits.  Each  of 
the  IDNX/10  interface  modules  has  a  built-in  channel 
service  unit  (CSU)  that  supports  D3/D4  or  extended  su¬ 
perframe  (ESF)  framing  patterns.  This  equipment  ac¬ 
cepts  direct  digital  connection  of  DSI  voice;  analog 
four-wire  E&M.  FXS/PLAR.  and  FXO;  low-speed  RS- 
232-C  synchronous  data:  and  N  x  56K/64K  synchro¬ 
nous  data  with  V.35. 

The  IDNX/10  provides  flexibility  in  configuring  net¬ 
works.  Users  with  small  sites  can  take  advantage  of  the 
full  array  of  backbone  services.  Furthermore.  DSO  com¬ 
patibility  with  carrier-based  services  lets  users  build  hy¬ 
brid  networks  combining  public  and  private  networks. 

IDNX/10  Hardware 

The  Main  System  Shelf  has  five  slots  that  can  hold  up  to 
two  Main  Modules,  two  T1  Interface  Modules,  and  one 
Sync  6/2  Data  Module.  Single  or  redundant  power  sup¬ 
plies  are  available.  As  an  option,  the  user  can  attach  the 
Channel  Module  Shelf  to  the  Main  System  Shelf  to  ex¬ 
tend  the  IDNX/10  capacity  and  functionality. 

The  Main  Module  contains  the  CPU.  memory,  and 
clocking  circuity.  This  module  also  has  six  I/O  interfaces 
that  accommodate  local  or  remote  connection  to  the 
Operator  Interface  for  network  management.  A  DSI  in¬ 
terface  permits  direct  connection  of  a  digital  PBX.  The 
module  also  supports  an  external  alarm  and  two  RS- 
232  data  ports. 

The  T1  Irrterface  Module  provides  a  DSO  channel¬ 
ized  trunk  that  is  compatible  with  both  the  private  and 
public  network  services,  including  fractional  T1.  An  op¬ 
tional  redundant  module  is  available  that  can  support 
redundant  hardware  or  T1  facilities. 

The  optional  Sync  6/2  Data  Module  provides  con¬ 
nection  for  up  to  eight  data  ports.  Two  V.35  ports  sup¬ 
port  speeds  of  up  to  256K  bps  in  increments  of  56K  bps 
or  64K  bps.  This  module  also  has  six  RS-232-C  ports 
for  data  rates  up  to  56K  bps.  The  Channel  Module  Shelf 
handles  high-speed  data  circuits,  up  to  1.344M  bps. 

The  Power  Supply  Module  distributes  power  to 
the  Main  System  Shelf.  An  optional  second  supply  can 
provide  redundancy.  Switchover  is  automatic  if  one  unit 
fails. 
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The  Channel  Module  Shelf  multiplexes  up  to  23 
channels.  These  can  be  any  combination  of  analog 
voice  and  synchronous  data.  The  channel  module  units 
support  4W  E&M  (I,  II),  FXS,  PLAR  LS/GS,  and  FXO 
voice  connections.  Data  ports  in  this  shelf  operate  in 
increments  of  56K  bps  or  64K  bps  up  to  1 .344M  bps 
with  V.35  or  RS-422  interfaces.  RS-232-C  interfaces  are 
available. 

The  Power  Converter/Ringer  Shelf  consists  of  a 
power  converter  module  that  performs  AC-to-DC  con¬ 
version  for  analog  voice  channel  units.  An  additional 
module  can  be  added  for  1:1  redundancy.  An  optional 
Ringer  Module  can  also  be  installed  in  this  shelf  to  pro¬ 
vide  ringdown  operation  for  FXS  appiications. 

IDNX/20 

The  IDNX/20  manages  private  utility  networks  con¬ 
sisting  of  various  types  of  transmission  techniques,  in¬ 
cluding  T1 .  The  IDNX/20  supports  a  maximum  of  1 5  T1 
lines.  In  addition,  this  product  provides  data  support  for 
the  following: 

•  RS-232-C  data  at  1 .2K  to  1 9.2K  bps  (DCE  or  DTE) 

•  V,35  and  RS-449/-422  data  at  1 .2K  to  1 .344M  bps 
(DCE  or  DTE) 

•  Biphase  data  at  1 .2K  to  96K  bps  (DCE) 

•  DDS  and  M24  compatible  (DSOA  compatible) 

The  IDNX/20's  AutoLoad  software  feature,  unique  to 
this  product,  automatically  loads  operating  software 
from  IDNX  nodes  in  the  network  upon  initial  start-up  or 
if  a  major  power  failure  occurs.  AutoLoad  helps  keep 
the  cost  of  common  equipment  oown  by  eliminating  the 
need  for  resident  software  storage  in  every  IDNX/20  in 
the  network. 

The  Basic  Operator  Interface  (BOI)  provides  diag¬ 
nostics.  debugging  commands,  and  node  and  trunk 
configurations.  The  BOI  is  not  AutoLoaded  but  is  stored 
permanently  in  nonvolatile  memory.  Alarms  are  user 
definable  and  customized,  and  the  network  can  be  ex¬ 
panded  without  the  operator  having  to  update  routing 
tables. 

Optional  equipment  for  the  IDNX/20  includes  a 
memory  module,  a  T1  jackfield,  and  an  alarm  panel.  The 
memory  module  provides  NVRAM  software  storage.  In 
a  network  with  no  1DNX/40S  or  lDNX/70s.  at  least  one 
memory  module  is  required  per  network.  System  soft¬ 
ware  is  distributed  automatically  by  the  AutoLoad  func¬ 
tion. 

IDNX/20  Hardware 

The  IDNX/20  consists  of  a  single-card  shelf  cabinet  with 
12  module  slots.  2  of  which  are  reserved  for  common 
logic.  The  IDNX/20  uses  a  more  highly  integrated  tech¬ 
nology  than  do  the  larger  models,  one  that  reduces  all 
common  logic  to  a  single  common  logic  board  (CLB). 
Two  versions  of  the  IDNX/20  are  available,  with  or  with¬ 
out  redundant  common  equipment.  Common  equipment 
includes  one  or  two  CLB  modules,  power  supplies. 
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power  distribution  unit,  and  cooling  devices.  Also  in¬ 
cluded  is  battery  backup  that  preserves  system  soft¬ 
ware  on  the  CLB  in  the  event  of  a  power  failure.  The 
entire  unit  is  rack  mounted  or  used  as  a  standalone  unit 
installed  in  an  lONX  cabinet. 

IDNX/20  24-Slot  Version 

The  24-slot  version  of  the  IDNX/20  actually  offers  two 
configurations:  12-slot  and  24-slot  versions.  A  customer 
whose  current  requirements  are  for  a  low-capacity  sys¬ 
tem  could  install  the  12-slot  version  and  then,  as  needs 
increase,  expand  it  to  a  24-slot  configuration. 

Both  redundant  and  nonredundant  models  are 
available.  Modules  are  mounted  in  one-  or  two-card 
shelf  cabinets  that,  in  turn,  are  mounted  in  standard  19- 
inch-wide,  7-foot-high  telco  cabinets  or  in  N.E.T.  IDNX/ 
40  or  /70  cabinets.  Each  shelf  holds  up  to  12  modules, 
power  supplies,  and  a  fan. 

In  the  12-slot  model,  the  processor  unit  (the  lov/er 
shelf)  has  12  modules,  2  of  which  are  reserved  for  com¬ 
mon  logic  board  (CLB)  modules.  With  the  24-slot  ver¬ 
sion,  a  second  shelf  (expansion  shelf)  contains  an 
additional  12  modules,  all  of  which  can  accommodate 
any  IDNX  trunk,  voice  port,  voice  compression,  or  data 
feature  modules.  No  additional  processors  are  required 
for  this  24-slot  version. 

The  CLB  occupies  a  single  shelf  slot  and  offers 
two  RS-232-C  ports  to  support  a  locally  attached  or  re¬ 
mote  dial-up  terminal  for  network  management.  An  op¬ 
tional  alarm  panel  can  also  connect  with  the  CLB. 

Two  power  supplies  are  needed  for  the  24-slot 
model.  Two  additional  power  supplies  can  be  added  for 
1:1  redundancy. 

Optional  equipment  includes  a  nonvolatile  random 
access  memory  (NVRAM)  module  for  software  storage. 
This  module  is  not  required  in  the  IDNX/20,  because  the 
software  is  automatically  downloaded  via  the  network 
from  a  neighboring  IDNX/20,  /40,  or  /70  system  in  the 
event  of  a  power  failure  on  the  IDNX/20.  A  network  that 
consists  only  of  IDNX/20  nodes,  however,  does  require 
one  memory  module  per  network.  An  external  rack¬ 
mounted  T1  jackfield  can  be  added  to  provide  test  ac¬ 
cess  to  T1  trunk  hardware.  A  rack-mounted  alarm  panel 
may  be  added  that  provides  audible  and  visual  alarm 
and  status  indicators. 

IONX/20  8-Slet  Version 

In  January  1990,  N.E.T.  introduced  its  IDNX/20  8-slot 
version.  This  is  identical  to  the  IDNX/20 12-slot  model 
except  that  its  capacity  is  reduced  by  four  slots  to  pro¬ 
vide  users  with  a  less  expensive  model.  Two  of  the 
eight  slots  are  for  common  logic  boards  (CLBs),  and  the 
remaining  six  are  available  for  IDNX  trunk,  voice,  and 
data  modules. 

This  product  is  available  in  redundant  or  nonre¬ 
dundant  configurations.  The  8-slot  IDNX/20  can  be  con¬ 
figured  for  up  to  six  T1  trunks  (three  if  a  redundant 
system).  It  supports  a  maximum  of  240  active  voice 
calls  with  one  trunk,  or  a  maximum  of  20  active  calls  up 
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to  64K  bps.  For  any  given  node,  the  number  of  originat¬ 
ing,  terminating,  and  pass-through  active  calls  is  1 .024. 

Users  can  upgrade  an  8-slot  IDNX/20  in  the  field 
by  adding  a  12-slot  expansion  shelf,  thus  producing  a 
20-slot  IDNX/20,  Two  slots  are  reserved  for  CLBs,  and 
the  remaining  eighteen  can  be  used  for  network  applica¬ 
tions.  The  20-siot  version  is  available  only  as  an  8-slot 
field  upgrade.  Both  the  8-slot  and  the  20-slot  IDNX/20s 
can  function  as  stand-alone  units  or  can  be  mounted  in 
cabinets  or  telco  racks. 

IDNX/40 

The  lDNX/40  supports  up  to  15  T1  lines.  It  integrates 
voice,  data,  facsimile,  and  video  bit  streams  overTI 
networks.  Nodes  can  be  added  without  operators  hav¬ 
ing  to  update  or  maintain  routing  tables.  The  lDNX/40 
supports  up  to  1 27  voice/data  channels  per  T 1  line  for 
efficient  bandwidth  utilization. 

The  equipment’s  Processor  Module  (CPU-2)  exe¬ 
cutes  the  nodal  software.  Based  on  an  MC58000  micro¬ 
processor,  this  module  occupies  one  slot  and  has  two 
RS-232-C  ports.  These  support  a  local  terminal  and/or  a 
modem  for  remote  dial-in  access.  An  optional  alarm 
panel  is  also  supported. 

The  Memory  Module  provides  nonvolatile  RAM 
storage  for  nodal  software  and  the  configuration  data¬ 
base.  New  software  releases  can  be  downloaded 
through  the  network  or  copied  from  another  Memory 
Module.  At  least  one  Memory  Module  is  required  for 
each  IDNX/40  node.  An  additional  module  can  be  used 
to  provide  redundancy. 

The  Clock  Module  provides  an  internal  timing 
source.  The  Clock  Module  can  also  use  up  to  eight  ex¬ 
ternal  sources  for  timing  references,  including  PBXs, 
DDS  circuits,  T1  facilities,  satellite  controllers,  or  a  sta¬ 
tion  clock.  If  a  clock  failure  occurs,  the  Clock  Module 
will  automatically  phase  lock  to  the  next  highest  priority 
source  or  onto  its  own  oscillator.  At  least  one  Clock 
Module  is  required  for  each  node.  An  additional  module 
can  be  used  for  redundancy. 

The  Time  Slot  Interchange  Module  (TSI-2)  per¬ 
forms  bus  management,  allowing  modules  to  communi¬ 
cate  with  each  other  by  providing  time  switching 
connectivity  among  modules.  At  least  one  TSI-2  module 
is  required  for  each  IDNX/40.  An  additional  module  can 
be  used  for  redundancy. 

IDNXI40  Hardwan 

The  IDNX/40  is  a  dual-row,  single-shelf,  24-slot  node  for 
lower  capacity  sites.  Modules  configured  in  the  IDNX/40 
are  the  same  as  those  used  in  an  IDNX/70  (see  below). 
The  IDNX/40  has  24  physical  slots  and  16  logical  slots. 
The  IDNX/40  can  hold  up  to  three  power  supplies.  One 
or  two  power  supplies  are  used  to  power  the  node,  and 
the  third  can  be  used  for  redundancy. 

IDNX/70 

The  IDNX/70’s  common  equipment  is  available  in  a  one- 
to  four-shelf  nonredundant  configuration  or  in  a  one-  to 
eight-shelf  redundant  configuration.  The  IDNX/70  is  an 
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expandable  transmission  resource  manager  for  high- 
capacity  network  implementation.  It  supports  up  to  96 
T1  lines  and  is  typically  installed  in  headquarters  or 
large  data  processing  centers.  An  lONX/70  can  be  up¬ 
graded  in  the  field  to  an  IDNX/90. 

IDNXI7Q  Hardware 

The  iDNX/70  is  a  single  unit  mounted  in  one  or  two  cabi¬ 
nets,  with  one  to  four  shelves  per  cabinet  and  one  to 
four  power  supply  shelves.  Two  cabinets  can  be  com¬ 
bined  to  form  an  eight-shelf  node.  Each  card  shelf  re¬ 
quires  one  power  supply,  and  power  supply  shelves  can 
hold  up  to  four  power  supplies.  Thus,  there  is  capacity 
for  hot  backup  power  supply  units. 

A  card  shelf  is  divided  into  a  front  portion  and  a 
back  portion  by  a  backplane.  The  module  is  a  printed 
circuit  board  assembly  consisting  of  a  front  card  and  a 
rear  interface  card  that  are  connected  through  the  back¬ 
plane.  on  which  the  pins  are  located. 

When  modules  are  configured  in  the  IDNX/70.  two 
things,  besides  the  number  of  physical  slots,  must  be 
taken  into  account;  the  amount  of  available  bandwidth 
and  the  power  requirements  of  the  configuration.  The 
number  of  logical  slots  required  by  each  module  type 
places  the  first  constraint  on  configuration.  A  logical  slot 
is  the  measure  of  the  backplane  bandwidth  require¬ 
ments  of  a  module.  Each  shelf  has  1 6  physical  slots  and 
1 6  logical  slots.  Second,  any  combination  of  modules  in 
a  shelf  should  not  exceed  a  power  requirement  of  45 
amperes.  Based  on  this  measure,  it  may  be  necessary 
to  arrange  the  modules  differently  among  the  shelves. 

The  front  cards  contain  the  logic  associated  with 
the  specific  processing  function  performed  by  the  mod¬ 
ule.  The  interface  card  provides  the  physical  interface 
for  external  equipment  (e.g.,  PBX,  computer  system, 
video  equipment)  to  the  IDNX.  Ports,  or  access  points, 
are  located  on  the  interface  card. 

IDNX/90 

The  IDNX/90  is  designed  as  a  platform  for  T3  services 
and  high-speed  applications  that  require  multimegabit 
transmission.  In  a  March  1988  position  paper  entitled 
“T3  Statement  of  Direction."  N.E.T.  explained  that  “in  a 
non-subrated  DS-3  format,  the  signal  can  take  whatever 
format  is  required  by  the  application,  the  only  require¬ 
ment  being  that  proper  framing  be  maintained.”  (N.E.T. 
expects  to  provide  channelized,  subrated  T3  in  the  fu¬ 
ture.)  The  new  IONX/90  is  designed  to  accommodate 
existing  IDNX  modules.  In  addition,  it  is  fully  compatible 
with  the  IDNX/70,  IDNX/40.  and  IDNX/20  resource  man¬ 
agers;  the  IONX/10  Integrated  Access  Multiplexer;  and 
the  company’s  complete  line  of  network  management 
products.  Customers  can  upgrade  an  IDNX/70  to  an 
IDNX/90  in  the  field. 

The  IONX/90  uses  the  Motorola  68030  high- 
performance  microprocessor;  it  provides  a  2S6M  bps, 
nonblocking,  switching  architecture.  The  T3  trunk  mod¬ 
ule  provides  support  for  IDNX  internodal  trunks  operat¬ 
ing  over  nonsubrate  T3  facilities.  This  module  can  allow 
such  networking  applications  as  LAN  interconneaivity, 
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host-to-host  communications,  distributed  graphics,  and 
supercomputer  networking. 

The  IDNX/90  supports  up  to  four  T3  connections; 
each  T3  trunk  module  provides  connection  for  a  single 
T3  circuit.  The  module  can  be  configured  for  1:1  redun¬ 
dancy  so  that,  if  the  IDNX/90  detects  a  fault,  it  can  auto¬ 
matically  switch  traffic  to  the  redundant  module. 


IDNX  Modules 

The  IDNX  supports  four  types  of  modules:  control  mod¬ 
ules.  T1/E1/64K  bps/56K  bps  trunk  modules,  port  mod¬ 
ules.  and  server  modules.  The  functions  of  these 
modules  are  described  below. 

Control  Modules 

Control  modules  control  or  manage  the  IDNX  internal 
logic.  They  are  the  common  equipment  modules  and  are 
required  in  each  IDNX.  The  control  modules  include  pro¬ 
cessor  and  memory,  TSI-2,  and  clock  modules. 

Processor  and  Memory  Modules 
The  processor  module,  which  controls  and  runs  the  sys¬ 
tem  software,  consists  of  a  front  CPU  card  and  a  rear 
interface  card.  The  front  card  is  called  the  CPU-2,  while 
the  CPU  cards  in  earlier  releases  were  known  as  CPUA. 
The  rear  interface  card  is  known  as  the  Input/output 
processor  (lOP).  The  front  card  contains  a  Motorola 
68000  microprocessor,  system  control  logic,  and  RAM. 

The  interface  card  has  two  RS-232-C  asynchro¬ 
nous  ports.  The  operator  console  uses  one  port  to  ac¬ 
cess  the  operator  interface.  The  second  port  is  typically 
used  for  connection  to  an  auto  answer  modem  for  re¬ 
mote  diagnostic  access,  as  an  additional  operator  con¬ 
sole,  or  as  a  printer  port  to  record  events. 

At  least  one  processor  module  and  one  memory 
module  must  be  installed  in  each  node  (or  two  each  for 
redundancy).  Additional  processor  modules  can  be  in¬ 
stalled  to  create  a  multiprocessor  environment  on  a 
node  to  handle  large  amounts  of  voice  and  data  traffic. 
When  two  or  more  processor  modules  are  used,  one  is 
the  master  and  the  others  operate  as  co-processors 
sharing  the  IDNX  work  load.  When  the  master  fails,  a 
co-processor  becomes  the  master.  The  operator  inter¬ 
face  determines  which  processor  module  functions  as 
the  master,  indicated  by  the  lights  on  the  card's  front 
panel.  One  memory  module  can  support  any  number  of 
processor  modules  on  a  single  node. 

TSh2  Modules 

The  time  slot  interchange  modules  control  information 
svntching  through  the  CPU-2  processor  modules  and 
other  cards  on  the  node  by  means  of  the  transport  bus. 
Nodes  supporting  CPUA  (software  prior  to  Release  6) 
run  with  TSI.  Both  TSI  and  TSI-2  provide  the  same  func¬ 
tionality.  TSl-2.  however,  provides  for  redundancy 
where  TSI  does  not.  The  TSI  module  uses  a  multiplexer 
interface  card.  This  is  the  only  module  that  must  be  in 
each  shelf  and  must  be  in  an  assigned  slot.  For  redun¬ 
dancy,  a  second  TSI  module  can  be  installed  on  each 
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Shelf.  The  second  TSI  module  must  be  installed  in  the 
slot  next  to  the  primary  TSI  module.  Most  CPUA  and 
TSI  modules  in  the  field  have  by  now  been  upgraded. 

Clock  Module 

The  clock  module  serves  as  an  internal  timing  source 
and  can  be  used  to  synchronize  an  entire  network.  This 
is  accomplished  by  phase-locking  to  the  appropriate 
reference  derived  from  ports,  trunks,  or  the  internal  os¬ 
cillator  on  the  clock  module  itself.  The  clock  module  can 
accept  a  timing  reference  from  any  one  DS1 ,  PRI,  PRC, 
INTL,  56K  TRK,  64K  TRK,  TMCP,  NXTK,  and  all  RS-422 
trunk  modules  as  well  as  universal  synchronous  data 
modules.  All  shelves  in  the  cabinet  receive  timing  from 
the  clock  module.  This  module  performs  ongoing  inter¬ 
nal  tests  to  monitor  the  eight  clocks  it  generates. 

The  CLK-2  card  provides  stratum  3  accuracy. 

With  Release  6  and  later  CLK-2  cards,  the  offline  card 
can  be  inserted  and  removed  without  interfering  with 
the  primary  card  by  repositioning  the  switch  on  the  front 
of  the  card.  There  must  be  at  least  one  clock  module  in 
each  node.  A  second  clock  module  can  be  installed 
through  the  operator  interface  for  reliability.  When  the 
IDNX  switches  to  the  redundant  clock  module,  the  node 
restarts.  During  a  power-up  condition,  the  modules  de¬ 
termine  which  clock  module  is  active. 

IDNX/20  CLB  Module 

The  CLB  module  incorporates  CPU,  time  slot  inter¬ 
change  (TSI),  and  clock  functions.  It  is  based  on  a  Mo¬ 
torola  68000  microprocessor.  Resident  memory 
includes  EPROM  for  the  Basic  Operator  Interface  (BOI) 
and  AutoLoad  feature,  RAM  for  system  software  stor¬ 
age  and  execution,  and  nonvolatile  RAM  (NVRAM)  for 
the  configuration  database.  The  CLB  occupies  a  single 
slot  in  the  IDNX/20  cabinet.  Two  RS-232-C  ports  are 
available  to  support  locally  attached  or  remote  dial-up 
terminals  for  network  management.  A  connector  on  the 
CLB  is  also  provided  for  an  interface  to  an  optional 
alarm  panel. 

Clocking  functions,  contained  in  the  CLB,  serve  as 
an  internal  timing  source  for  synchronizing  the  node. 
The  CLB  also  performs  bus  management  and  time  slot 
interchange  functions  which  provide  connectivity  among 
modules  contained  in  the  IDNX/20. 

Trunk  Module* 

Trunk  modules  contain  logic  to  control  the  flow  of  infor¬ 
mation  into  the  T1  facilities.  The  trunk  module  is  the 
point  at  which  a  call  (either  voice  or  data)  leaves  the 
node  (IDNX)  and  enters  the  network  or  arrives  from  a 
remote  node.  A  call  is  the  virtual  port-to-port  circuit  built 
by  the  supervisor  software.  Trunk  modules  function  as 
frame  builders  and  work  in  conjunction  with  the  proces¬ 
sor  module  to  allocate  and  deallocate  trunk  channels. 
The  modules  contain  realtime  multiplexing,  synchroni¬ 
zation,  and  control  logic,  and  they  support  standard  Red 
and  Yellow  alarms.  The  nine  trunk  modules  are  the 
IDNXT1  trunk.  MIL-188.  RS-422.  CEPT,  56K.  CMIT, 
NXTK,  International  422.  and  64K. 
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T1  Trunk  Module 

The  T1  trunk  module  supports  one  T1  trunk  (1 .544M 
bps).  It  functions  as  the  frame  builder  and  works  in  con 
junction  with  the  processor  module  to  allocate  and  deai 
locate  trunk  channels.  The  module  contains  realtime 
multiplexing,  synchronization,  and  control  logic  and 
supports  standard  Red  and  Yellow  alarms.  For  one-to- 
one  redundancy,  a  backup  trunk  module  can  be  in¬ 
stalled.  Redundancy  is  accomplished  through  hardwar? 
cabling  and  through  a  trunk  parameter  in  the  operator 
interface. 

The  rear  interface  card  in  the  T1  trunk  module  is 
called  the  Bandwidth  Efficient  Zero  Suppressing  (BEZ£ 
card  and  provides  zero  suppression  per  Bell  Pubileatio 
62411  (i.e.,  no  more  than  15  consecutive  zeros  are  gen 
erated).  This  one  insertion  method  requires  only  2  per¬ 
cent  (32K  bps)  of  the  T1  bandwidth.  No  errors  are 
introduced  by  inserting  ones.  The  speed  of  this  card  is 
1.544K  bps. 

An  alternate  zero  suppression  method,  modeled 
after  CCITT  recommendation  G.922.  is  also  provided  o 
the  BEZS  interface  card.  This  method,  called  Maximurr 
Bandwidth  Zero  Suppression  (MBZS),  forces  the  3ist 
bit  to  1  if  there  are  30  preceding  zeros.  This  method 
uses  no  bandwidth  but  can  introduce  errors  in  the 
datastream.  This  method  is  now  rarely  used. 

MIL-188  Trunk  Module 

This  trunk  module  runs  at  256K  bps  or  51 2K  bps  and 
supports  encryption  equipment.  This  module  is  rarely 
used. 

RS-422  Trunk 

The  RS-422  trunk  interface  provides  for  data  conver¬ 
sion  between  the  trunk  card  and  a  synchronous  high¬ 
speed  serial  data  circuit.  The  interface  card  is  backwar 
compatible  with  the  MIL-188  trunk  interface.  The  RS- 
422  trunk  supports  ail  the  features  supported  by  the 
MIL-188  trunk.  In  addition,  it  can  operate  at  eight  differ 
ent  data  speeds  (256K  bps.  384K  bps,  512K  bps,  672K 
bps,  1.024K  bps,  1.344K  bps,  1.544K  bps,  2.048K  bps) 
The  speeds  are  set  through  the  hardware.  The  interfac 
meets  all  MIL-188  specifications  as  well  as  the  RS-422 
specifications  and  supports  encryption  equipment. 

CEPT  Trunk 

This  interface  supports  the  CCITT  G.703/704  line  en¬ 
coding  and  framing  scheme.  CEPT  trunk  functions  in¬ 
clude  data  recovery,  frame  generation  and  recovery, 
serial-to-parallel-to-serial  conversion,  and  timing  sig¬ 
nals.  CEPT  trunk  speed  is  2.048K  bps.  It  supports  en¬ 
cryption  equipment. 

56K  Trunk 

The  56K  trunk  module  provides  all  IDNXs  with  a  subra 
trunk  that  operates  at  56K  bps,  and  it  can  be  used  to 
back  up  a  T1  trunk  for  critical  circuits,  as  a  temporary 
trunk  while  T1  facilities  are  being  installed,  as  a  supple 
mental  trunk  to  a  T1  trunk,  or  as  a  subrate  trunk  to  a  u 
node.  The  56K  interface  card  supports  encryption  but 
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does  not  support  transparent  signaling  rates  and  pass¬ 
through  timing  from  the  universal  synchronous  data 
card,  24K  bps  compressed  voice.  A  56K  trunk  supports 
one  56K  bps  trunk  line. 

Coded  Mark  Inversion  Trunk  Module 
The  Coded  Mark  Inversion  Trunk  (CMIT)  module  sup- 
pons  the  line  encoding  (Coded  Mark  inversion)  used  by 
the  high-speed  digital  networks  of  Japan.  The  standard 
1 .544M  bps  line  speed  is  supported  by  the  CMI.T  mod¬ 
ule  and  lets  the  user  properly  frame  data  at  four  speeds: 
192K  bps.  384K  bps.  768K  bps.  and  1.536M  bps.  This 
module  provides  the  same  functionality  as  the  Tt  trunk 
module,  including  internodal  signaling  and  support  for 
voice  compression. 

1.920-X.21  Trunk  (NXTX)  Module 
The  NXTX  Trunk  module  supports  internodal  trunks  that 
operate  through  1.920M  bps  trunk  facilities,  such  as 
Transfix  in  France.  The  interface  is  compatible  with  X.21 
electrical  and  physical  standards. 

International  RS-422  Trunk  Module 
The  INT422  Trunk  module  is  intended  for  those  applica¬ 
tions  that  require  support  for  narrower  bandwidth  appli¬ 
cations.  such  as  128K  bps  and  192K  bps.  N.E.T.  has 
found  that  clients  usually  do  not  distinguish  between 
international  and  other  RS-422  applications. 

The  INT422  Trunk  module  operates  at  the  follow¬ 
ing  eight  rates:  128K  bps,  192K  bps,  256K  bps,  384K 
bps,  51 2K  bps.  768K  bps,  1.536K  bps.  and  1.544K  bps 
bps.  This  list  includes  three  new  rates:  128K  bps,  192K 
bps.  and  1.536K  bps.  The  rates  of  1.024K  bps.  1.344K 
bps.  and  2.048K  bps  will  continue  to  be  supported  in  the 
current  RS-422  Trunk  module. 

64K  Trunk  Module 

The  64K  is  a  new  trunk  module  that  supports  both  an 
X.21  and  a  V.35  interface.  This  operates  as  a  low-speed 
trunk  or  as  a  backup  to  critical  higher  speed  circuits. 

Port  Modulos 

Port  modules  connect  external  equipment  (e.g.,  PBX, 
computer  system,  terminal,  statistical  multiplexer,  video 
equipment,  etc.)  to  the  IDNX.  There  are  two  types  of 
modules:  data  and  voice. 

Data  Port  Modules 

Data  port  modules  manage  the  interface  between  syn¬ 
chronous  data  devices  (e.g.,  modem,  front-end  proces¬ 
sor,  statistical  multiplexer,  host  computer  port,  etc.)  and 
the  IDNX.  Data  port  modules  are  divided  into  three 
groups:  low-speed,  high-speed,  and  universal  synchro¬ 
nous  data.  Each  data  port  module  supports  remote  and 
local  loop  via  switch,  signal,  or  the  operator  interface. 
Redundant  data  cards  are  not  installed  on  the  node.  Ex¬ 
tra  data  cards  can  be  purchased  for  replacement  upon 
failure  of  a  data  card  on  the  node.  Table  1  lists  the 
speeds  for  the  IDNX  data  port  modules.  Table  2  lists  the 
ports  and  interfaces. 
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DSOA  Module:  The  DSOA  module  provides  four  inoe- 
pendent,  synchronous  data  ports  with  RS-232-C  DCE  or 
DTE  interfaces  at  rates  from  2.4K  bps  to  64K  bps  and 
incorporates  32  bits  of  buffering  for  long-haul  and  multi¬ 
polling  tail  circuits.  It  transports  synchronous  data  be¬ 
tween  IDNX  and  DDS  networks  and  is  compatible  with 
the  Dataphone  Digital  Service  (DDS)  specifications.  The 
DSOA  module  allows  data  to  be  passed  between  a  data 
terminal  (DTE  or  DCE)  and  a  64K  bps  DSO  channel  on  a 
primary  rate  card  in  a  permanent  circuit. 

Quad  Synchronous  Data  Module:  The  Quad  Synchro¬ 
nous  Data  (QSD-2)  module  provides  four  independent, 
rate-selectable,  half-  or  full-duplex  synchronous  circuits 
and  is  configured  as  a  data  communications  equipment 
(DCE)  or  a  data  terminal  equipment  (DTE)  electrical  in¬ 
terface.  Rates  from  1.2K  bps  to  19.2K  bps  support  the 
RS-232  DCE  or  DTE  interface.  Rates  from  1 .2K  bps  to 
56K  bps  support  the  V.35  DCE  or  DTE  interface. 

Quad  Asynchronous/Synchronous  Data  Module:  The 
QASD  module  provides  4  independent  asynchronous/ 
synchronous  data  ports  with  V.35  DCE/DTE  or  RS-232 
DCE/DTE  interfaces.  The  DCE  interface  cards  provide 
transmit  and  receive  timing  from  external  DCE.  Optional 
Terminal  Timing  (TT)  can  be  used,  depending  on  the 
application.  This  compensates  for  phase  shifts  in  Send 
Data  relative  to  Send  Timing  signals.  TT  is  often  justified 
with  tail  circuit  modems,  high  bit  rates,  long  cable  runs, 
or  certain  other  terminal  equipment  requirements.  TT  is 
supported  on  both  the  DCE  and  DTE  interfaces. 

High-Speed  Synchronous  Data  Module:  The  high¬ 
speed  synchronous  data  (HSD)  module  supports  two 
independent,  rate-selectable,  full-duplex  circuits  with 
V.35  DCE/DTE  or  RS-422  DCE/DTE  interfaces  at  rates 
from  9.6K  bps  to  1 .344M  bps  and  RS-232-C  DCE/DTE 
interfaces  at  rates  from  1 .2K  bps  to  1 9.2K  bps.  The 
module  requires  from  one  fourth  to  two  full  logical  slots, 
depending  on  the  speed  selected. 

High-Speed  Data  Module:  The  HSD-2  module  is  a  su¬ 
perset  of  the  HSD  module.  Each  HSD-2  module  port 
operates  in  either  emulation  mode  (in  which  it  emulates 
the  HSD  module)  or  native  mode.  In  native  mode  the 
ports  can  support  N  X  56K  bps  or  N  x  64K  bps  data 
rates  up  to  1 .544M  bps.  In  native  mode  connections  can 
be  made  to  the  PRC  module.  This  feature  lets  calls  be 
placed  between  the  IDNX/10  high-speed  data  ports  and 
the  HSD-2  module  ports. 

Universal  Synchronous  Data  Module:  The  universal 
synchronous  data  (USD)  module  provides  two  indepen¬ 
dent,  rate-selectable,  full-duplex  circuits  with  V.35  DCE/ 
DTE  or  RS-422  DCE/DTE  interfaces  at  rates  from  1 .2K 
bps  to  1.344M  bps  and  RS-232-C  DCE/DTE  interfaces 
at  rates  from  1.2K  bps  to  19.2K  bps.  The  module  also 
supports  biphase  DCE  interface  at  rates  of  1 .2K  bps  to 
96K  bps  (through  a  hardware  DIP  switch).  The  electrical 
interface  is  MIL-188.  The  biphase  interface  provides 
Manchester  encoding  that  allows  clock  information  to 
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Table  1.  Data  Rates  Available  for  IDNX  Data  Port  Modules  (in  bps) 


QASD 


USD 

HSD 

QSD-2 

Sync 

Async 

DSOA 

OMD 

QXP 

HSO-2 

9600 

1200 

1200 

75 

1200 

1200 

1200 

144.0K 

1800 

12.8K 

1800 

1800 

150 

2400 

1800 

1800 

153.6K 

2400 

19.2K 

2400 

2400 

300 

4800 

2400 

3600 

234.0K 

3200 

32.0K 

3600 

3600 

600 

8000 

3600 

7200 

336.0K 

3600 

38.4K 

4800 

4800 

1200 

9600 

4800 

14.4K 

.  672.0K 

4800 

48.0K 

7200 

7200 

1800 

16.0K 

7200 

16.0K 

1.152M 

6400 

56.0K 

9600 

9600 

2400 

32.0K 

9600 

19.2K 

1.536M 

7200 

57.6K 

14.4K 

12.0K 

3600 

56.0K 

14.4K 

28.8K 

1.544M 

8000 

64.0K 

16.0K 

12.8K 

4800 

64.0K 

16.0K 

32.0K 

9600 

72.0K 

19.2K 

14.4K 

7200 

19.2K 

38.4K 

12.8K 

96.0K 

28.0K 

16.0K 

9600 

28.8K 

56.0K 

14.4K 

112.0K 

32.0K 

16.8K 

14.4K 

32.0K 

64.0K 

16.0K 

115.2K 

38.4K 

19.2K 

16.0K 

38.4K 

16.8K 

128.0K 

48.0K 

24.0K 

19.2K 

48.0K 

19.2K 

168.0K 

56.0K 

28.0K 

56.0K 

24.0K 

192.0K 

32.0K 

28.8K 

224.0K 

38.4K 

32.0K 

230.4K 

48.0K 

38.4K 

256.0K 

56.0K 

48.0K 

384.0K 

57.6K 

56.0K 

448.0K 

64.0K 

57.6K  512.0K 

64.0K  768.0K 

72.0K  896.0K 

76.8K  1.024M 

84.0K  1.344M 

96.0K 

112.0K 

115.2K 

128.0K 

144.0K 

168.0K 

192.0K 

224.0K 

230.4K 

256.0K 

288.0K 

336.0K 

384.0K 

448.0K 

512.0K 

102.4M 

134.4M 
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Table  2. 

Port  and  interfaces 

USD 

HSD  ' 

QSO-2/QASD 

DSOA 

DMD 

QXP 

No.  of  Ports 

2 

2 

4 

4 

4  external 

4  internal 

4 

Irtterfaees 

DCE 

RS-232-C 

RS-449/-422 

V.35 

Biphase 

RS-232-C 

RS-449/-422 

V.35 

RS-232-C 

V.35 

RS-232-C 

V.35 

RS-232.C 

V.35 

X.21 

DTE 

RS-232-C 

RS-449M22 

V.35 

RS-232-C 

RS-449/-422 

V.35 

RS-232-C 

V.54 

V.35 

RS-232-C 

V.35 

RS-232-C 

V.54 

X.21 

be  imbedded  into  and  recovered  from  the  datastream. 
The  module  requires  from  one  fourth  to  two  full  logical 
slots,  depending  on  the  rate  selected. 

A  data  port  configured  as  DTE  on  the  universal 
synchronous  data  module  can  be  used  as  a  network 
timing  source.  It  also  allows  data  circuits  to  run  asyn* 
chronously  to  the  network  clock  and  accommodates 
special  signaling  requirements.  Pass-through  timing, 
not  locked  to  the  internal  IDNX  network  clock,  allows  an 
independently  synchronized  data  circuit  to  be  passed 
through  the  IDNX  without  data  loss  due  to  a  frequency 
slippage. 

Digital  Multidrop  Data  (DMD)  Module:  The  Digital  Multi¬ 
drop  Data  (DMD)  module  connects  multiple  terminals  to 
a  single  data  channel  in  the  network.  It  offers  four  exter¬ 
nal  ports  for  local  or  tail  circuit  connections  to  terminals 
or  terminal  controllers  and  four  internal  ports  for  net¬ 
work  connections.  Three  of  these  internal  ports  permit 
cascaded  configurations  of  multiple  DMD  modules  in 
the  IDNX  network.  The  fourth  internal  port  (Port  0)  pro¬ 
vides  the  link  between  the  front-end  processor  and  all 
other  ports  on  the  module.  The  external  ports  can  be 
either  looped  in,  toward  the  network,  or  out,  toward  the 
terminal.  The  DMD  performs  automatic  loop  testing  on 
each  external  port  during  power-up  procedures  of  upon 
getting  an  operator  command.  When  the  test  is  com¬ 
pleted,  the  external  ports  are  restored  to  their  original 
states.  The  OMO  module  supports  synchronous  data  at 
speeds  ranging  from  1200  bps  to  56K  bps. 

Quad  X.21  Port  Module:  The  Quad  X.21  Port  (QXP) 
module  is  used  to  interface  to  a  leased  X.21  circuit  or  to 
provide  a  gateway  to  public  X.21  networks.  When  used 
in  conjunction  with  an  existing  QSD-2  module,  the  QXP 
module  provides  X.21-to-X.21  bis  interface  conversion 
and  allows  devices  with  differing  Interfaces  to  communi¬ 
cate  with  one  another. 

When  the  QXP  module  is  configured  with  a  DCE 
interface,  it  can  detect  network  loops  generated  by  ex¬ 
ternal  and  modem  signals.  This  module  provides  four 
independent  X.21  interfaces  for  data  communications.  It 


is  available  in  both  DCE  and  DTE  versions  and  supports 
speeds  from  1200  bps  to  64K  bps. 

V.54  Support  for  QSO-2  and  QASO  Interfaces:  A  new 
rear  card  is  offered  for  the  QSD-2  and  QASD  that  pro¬ 
vides  a  V.54  DTE  interface  for  standardized  loop-back 
modem  testing. 

Voice  Port  Modules 

Voice  modules  manage  calls  coming  into  and  lea\ing 
the  IDNX  network. 

DS1  Module:  The  DS1  module  manages  the  interface 
between  voice  communications  equipment  (analog  and 
digital  PBXs,  D3/D4  channelbanks.  etc.)  and  the  IDNX. 
The  DS1  module  has  two  pulse  code  modulation  (PCM) 
channel  groups  (commonly  known  as  digroups).  The 
channel  groups,  each  containing  24  ports,  are  con¬ 
nected  to  voice  communications  equipment.  This  mod¬ 
ule  separates  the  incoming  24-channel  PCM  frames  and 
recovers  the  A  and  B  channel  signaling  bits,  it  accepts 
timing  from  the  internal  IDNX  network  clock,  the  chan- 
nelbank,  or  the  digital  PBX.  The  module  supports  stan¬ 
dard  Red  and  Yellow  alarms.  N.E.T.  reports  that  the 
Primary  Rate  module  is  now  shipped  more  than  the  DS1 
module. 

Primary  Rate  Card  Module:  The  Primary  Rate  Card 
(PRC)  module  has  two  modes:  emulation  and  native. 

The  card  powers  up  in  emulation  mode,  functioning  ex¬ 
actly  as  does  a  OS1  module.  In  native  mode,  it  provides 
ail  of  the  DS1  module  features  as  well  as  ESP  capabili¬ 
ties  and  diagnostics,  zero  suppression  techniques, 
clear  channel,  clock  reference  settings  through  the  soft¬ 
ware,  aggregate  circuits,  and  digroup  independence. 
The  PRC  module  has  two  PCM  digroups,  each  contain¬ 
ing  24  ports.  In  native  mode,  the  digroups  may  build  cir¬ 
cuits  to  DSOA  modules,  to  other  PRC  modules  in  native 
mode,  or  to  DS1  modules.  In  emulation  mode,  the  di¬ 
groups  can  only  build  circuits  to  DS1  modules  or  PRC 
modules  in  emulation  mode.  The  PRC  module  also  sup¬ 
ports  unrestricted  clear  channels  or  robbed-bit  signaling 
configurable  on  a  per-channel  basis. 
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The  interface  card  provides  a  DS1  bipolar  signal 
interface  to  two  DS1  lines  supporting  a  total  of  48  ports. 

A  backup  PRC  module  provides  one-for-one  redun¬ 
dancy.  This  module  accepts  timing  from  the  internal 
IDNX  network  clock,  the  channelbank.  or  the  digital 
PBX. 

Two-Megabit  Channelized  Port  (TMCP)  Module:  The 
TMCP  module  is  a  2.048M  bps  channelized  port  inter¬ 
face  that  accepts  two  G.704-formatted  signals  from 
channel  banks  and  digital  PBXs.  This  module  is  compat¬ 
ible  with  CCITT  G.703,  G.704,  and  G.732  specifications. 
The  TMCP  module  can  also  perform  gateway  functions 
to  allow  devices  with  different  formats  and  protocols  in 
an  IDNX  network  to  communicate  with  one  another.  In 
addition,  the  TMCP  module  supports  transparent  signal¬ 
ing. 

Server  Module 

The  server  module  increases  the  trunk  lines  voice  call 
capacity  by  compressing  the  voice  signal.  Voice  calls 
originate  and  terminate  on  DS1  modules,  PRC  modules. 
TMCP  modules,  or  QAVP  modules.  All  server  modules 
may  be  used  with  a  PRC  module  that  is  running  in  either 
emulation  or  native  mode. 

DSP  Module 

The  digital  speech  processing  (DSP)  module  provides 
voice  call  compression  from  64K  bps  on  24  channels 
onto  32K  bps  toll-equivalent  ADPCM  circuits.  It  allows 
up  to  47  simultaneous  conversations  on  IDNX  T1 
trunks.  One  DSP  card  can  handle  24  channels.  There¬ 
fore,  two  DSP  modules  are  required  to  handle  the  full 
load  of  a  DSI  or  PRC  module.  The  module  is  shared  on 
an  as-required  basis  equally  among  all  DSI  or  PRC 
modules  on  the  node.  A  single  DSP  module  can  provide 
backup  for  any  number  of  active  DSP  modules  (1  :N  re¬ 
dundancy). 

Both  end-to-end  and  intermediate  voice  compres¬ 
sion  are  supported  within  a  network.  This  requires  that 
a  DSP  module  be  available  on  the  origination  and  desti¬ 
nation  node  (to  compress  and  decompress  the  call),  but 
a  DSP  module  is  not  required  on  intermediate  nodes. 

A  call  can  be  designated  for  DSP  at  the  origination 
node.  If  a  DSP  module  is  not  available,  the  call  is  sent  as 
PCM.  When  the  call  goes  through  an  intermediate  node 
that  has  a  DSP  module  available,  the  call  is  compressed 
to  DSP. 

VC31  and  VC62  Modules 

The  VC31  and  VC62  modules  provide  the  two  ADPCM 
voice  compression  types:  32K  bps  CCITT  and  24K  bps 
N.E.T.  proprietary.  Mu-law  and  A-law  sampling  and 
compression  are  both  supported.  The  VC31  module 
provides  voice  call  compression  from  64K  bps  on  31 
full-duplex  PCM  voice  circuits  onto  either  32K  bps  or 
24K  bps  circuits.  There  are  32  channels  in  one 
transcoder,  1  of  which  is  used  for  realtime  diagnostics. 
The  VC62  module  provides  voice  call  compression  from 
64K  bps  on  62  full-duplex  PCM  voice  circuits  onto  either 


32K  bps  or  24K  bps  circuits.  There  are  64  channels  in 
two  transcoders  (32  channels  each).  One  of  the  chan¬ 
nels  in  each  transcoder  (two  channels  total)  is  used  for 
continuous  realtime  diagnostics  and  is  unavailable  for 
use  as  a  compression  channel. 

Two  VC31  modules  are  required  to  support  one 
DSI  or  PRC  module,  and  one  VC62  module  supports 
one  DS1  or  PRC.  The  module  is  shared  on  an  as- 
required  basis  equally  among  all  DSI  or  PRC  modules 
on  the  node.  If  a  VC31  or  VC62  module  is  not  available 
when  the  call  is  originated,  the  call  is  sent  as  PCM. 
When  the  call  goes  through  an  intermediate  node  that 
has  a  VC31  or  VC62  module  available,  the  call  is  com¬ 
pressed  to  VC31  orVC62. 


New  Modules 

In  May  1990.  N.E.T.  introduced  its  High-Density  Voice 
Compression  (HDVC)  module  and  the  Quad  Analog 
Voice  Port  (QAVP). 

High*D«nsity  Voice  Compression  Module 

The  HDVC  module  is  scheduled  to  be  available  this 
quarter. 

The  HDVC  uses  Vector  Adaptive  Predictive  Cod¬ 
ing.  This  module  enables  8K  and  16K  bps  compression 
on  IDNX  voice  circui's.  This  rate  of  compression  in¬ 
creases  the  call  capacity  of  internodal  trunks,  thus  max¬ 
imizing  current  bandwidth  utilization,  in  addition,  it 
reduces  the  need  for  future  additional  bandwidth. 

With  the  HDVC’s  server  architecture,  a  single 
module  can  be  shared  by  a  number  of  voice  ports  in  a 
node,  as  well  as  by  several  nodes  in  a  network. 

The  HDVC  module  is  available  in  two  forms:  the 
HDVC/24.  which  accommodates  up  to  twenty-four  64K 
bps  channels:  and  the  HDVC/12,  which  accommodates 
up  to  twelve  64K  bps  channels. 

The  HDVC  module  is  designed  both  for  domestic 
and  international  applications.  N.E.T.  believes  that,  be¬ 
cause  bandwidth  is  relatively  expensive  in  Europe  and 
East  Asia,  the  HDVC  module  should  be  especially  useful 
in  these  markets. 

Quad  Analog  Voiea  Pert 

The  QAVP  module  is  scheduled  to  be  available  this 
quarter. 

The  QAVP  module  provides  a  direct  analog  inter¬ 
face  for  the  IDNX.  This  module  eliminates  the  need  for 
external  channel  banks  and  echo  cancellers;  it  is  useful 
for  low-density  sites  requiring  support  for  analog  cir¬ 
cuits.  The  QAVP  module  has  a  four-wire  E&M  interface 
and  supports  signaling  types  I  through  V,  SSDC5A.  This 
module  is  designed  for  both  domestic  and  international 
applications. 
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The  ACS  4130  links  a  TCP/IP 
local  area  network  into  an  inte¬ 
grated  wide-area  network  over  both 
point-to-point  lines  and  X.25  data 
networks.  ACC’s  ACS  41 30  IP 
Router  meets  the  requirements  of 
heavy  data  traffic  loads  by  seg¬ 
menting  data  flow  into  local  sub¬ 
nets.  Using  dynamic  routing  proto¬ 
cols,  the  ACS  41 30  finds  the  short¬ 
est  path  to  forward  a  packet,  and 
avoids  delays  associated  with 
congested  or  failed  circuits.  Traffic 
is  routed  to  the  packet’s  destination, 
instead  of  through  the  entire  network. 

For  DoD  applications,  the  ACS 
4130  has  basic  IP  security  options. 

It  also  provides  network  manage¬ 
ment  using  the  TCP/IP  Simple 
Network  Management  Protocol 
(SNMP).  With  SNMP,  a  user  can 
monitor  and  control  the  internet- 
worked  topology  of  ACS  4130s. 

The  ACS  4130  provides  TCP/IP 
network  node  access  across  X.25 
public  and  private  data  networks 
such  as  Telenet,  Tymnet,  Accunet, 
the  Defense  Data  Network  (DDN), 
and  International  Public  Networks. 


ACS  4130  Features 

•  Dynamic  and  static  routing 

•  Subnetwork  addressing 

•  Multiple  serial  ports 

•  SNMP  network  management 

•  X.25  support 

Product  Adaptability 

As  your  network  changes,  the 
ACS  4130  can  take  on  new  capa¬ 
bilities  to  keep  pace  with  your 
growing  requirements.  All  of  ACC’s 
Series  4000  advanced  internet¬ 
working  products  share  the  same 
powerful  hardware  base.  So  differ¬ 
ent  ACS  4000  bridge  and  router 
models  (which  are  different  soft¬ 
ware  packages)  can  be  intercon¬ 
nected  in  a  single  extended  LAN. 
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By  evaluating  the  hops  between  the  packet’s  current  location  and  final  destination,  the  ACS  4 130 
chooses  the  shortest  route. 


The  ACS  4130  is  housed  in  a 
standalone  enclosure  that  easily 
installs  on  your  existing  network. 
You  can  access  system  commands 
locally  or  remotely  to  set  operating 
parameters,  display  statistics  or 
manually  set  routing  tables. 

In  today’s  expanding  TCP/IP 
marketplace,  the  ACS  4130  pro¬ 
vides  the  flexibility  needed  in 
networks  with  heavy  data  flow  and 
multiple  layers  of  redundancy. 

While  both  bridges  and  routers 
forward  data  between  networks,  the 
ACS  41 30  offers  significant  advan¬ 
tages  over  bridges. 

Standard  Router  Features 

The  ACS  4130  combines  stan¬ 
dard  routing  capabilities  with 
second  generation  features  to 
create  a  product  with  performance 
and  flexibility  that  today’s  increas¬ 
ingly  complex  networks  demand. 

Dynamic  IP  Routing  determines 
the  optimal  path  to  forward  data. 

Since  the  ACS  4130  IP  Router 
operates  at  the  Network  layer  of  the 
OSI  model,  it  examines  messages 
specifically  sent  to  it  for  routing  to 
other  networks  and  makes  intelli¬ 
gent  decisions  about  how  to  send 
packets  down  various  paths  to  their 
proper  destination.  The  Routing 
Information  Protocol  (RIP)  analyzes 
the  number  of  nodes  the  packet 
travels  across  to  reach  its  destina¬ 
tion,  and  chooses  the  shortest 
route. 


Through  RIP,  the  ACS  4130 
discovers  information  about  the 
network  and  shares  it  with  other 
routers,  sending  routing  updates  at 
user-selected  intervals.  Once 
collected, .the  information  is  incorpo¬ 
rated  into  routing  tables. 

Dynamic  routing  automatically 
accommodates  network  changes, 
keeping  communication  flowing. 

Routing  tables  are  configured 
automatically.  The  ACS  4130  main¬ 
tains  its  own  internal  network 
routing  tables  as  it  receives  routing 
updates.  As  it  learns  new  network 
destinations,  the  ACS  4130  adds 
them  to  the  current  table  automati¬ 
cally. 

You  can  also  customize  the  ACS 
41 30’s  routing  tables  through  static 
routing.  By  manually  programming 


routing  tables,  you  can  instruct  the 
ACS  41 30  to  disregard  specific 
packets.  Through  combined  use  of 
both  static  and  dynamic  routing, 
you  maintain  the  benefits  of  dy¬ 
namic  routing,  yet  still  have  the 
overriding  control  of  your  extended 
network. 

Subnetworks  direct  where 
packets  are  forwarded. 

The  ACS  41 30  takes  advantage 
of  protocol-specific  capabilities  such 
as  IP  address  classes  and  subnets. 
It  retains  separate  subnetwork 
identities.  With  these,  you  can 
easily  divide  a  set  of  connected 
networks  into  locally  controlled 
administrative  regions.  Packets 
coming  from  one  network  are 
directly  forwarded  to  specific 
subnets,  and  their  final  destination. 


Advanced  Features 

Large  interconnected  TCP/IP 
networks  create  new  challenges. 
Complex  topologies  spread  across 
^  several  sites  require  centralized 
network  management  and  high 
throughput.  The  ACS  4130  re¬ 
sponds  to  these  new  challenges 
,  with  second  generation  features 
that  guarantee  high  performance 
and  continuous  reliability. 

Multiple  serial  ports  provide 
configuration  flexibility  and 
performance  options. 

Multiple  serial  ports  offer  configu¬ 
ration  flexibility.  The  ACS  4130 
connects  to  either  standard  or 
thinwire  802.3  Ethernets  and 
supports  a  high  speed  point-to-point 
"•••ial  and  X.25  connection.  Serial 

ts  can  be  any  combination  of 
RS-232,  RS-422/449,  RS-530,  or 
V.35  electrical  interfaces. 

Multiple  serial  ports  offer  per¬ 
formance  advantages  on  both  large 
and  small  extended  networks.  On 
simple  configurations  bf  two  Eth¬ 


ernets,  multiple  serial  links  can 
provide  redundant  connections  and 
also  automatically  level  the  traffic 
load  for  continuous  high  throughput. 

On  larger  topologies,  multiple 
serial  ports  can  be  separated  to 
connect  LANs  in  different  direc¬ 
tions. 

Multiple  serial  lines  provide  high 
throughput. 

The  ACS  4130’s  multiple  serial 
lines  provide  aggregate  speeds 
from  4.8  Kbits/sec  up  to  2.048 
Mbits/sec.  Serial  lines  from  a  single 
ACS  4130  can  transmit  data  at 
different  speeds.  For  example,  one 
link  could  provide  T1  capability, 
while  the  other  runs  at  56  Kbps  into 
an  X.25  packet-switched  network. 

Network  Management  lets  you 
control  use  and  operation. 

A  single  ACS  4130  can  monitor 
and  control  other  ACS  4130  units 
on  the  internetwork.  To  indicate 
error  alerts,  it  sends  alarms  to  a 
user-selectable  location. 


ACS  4130  IP  Routers  function  as 
Simple  Network  Management 
Protocol  (SNMP)  clients  and 
agents,  collecting  data  about  their 
connected  segments  and  reporting 
to  network  management  systems 
that  use  SNMP. 

The  centralized  management 
system  displays  operating  statistics 
for  any  ACS  41 30  (or  other  internet¬ 
working  device  using  SNMP)  on  the 
extended  network  to  let  you  monitor 
network  performance.  It  also  lets 
you  change  system  parameters, 
modify  routing  tables,  and  activate 
or  inactivate  any  network  links. 

SNMP  evolved  from  a  need  for 
network  management  that  extended 
beyond  a  single  LAN.  With  its  large 
installed  base  and  time-proven  field 
performance,  SNMP  is  the  ac¬ 
cepted  standard  for  managing  the 
full  range  of  network  devices. 

X.25  provides  network  alter¬ 
natives  and  network  reliability 
through  redundant  links. 

The  ACS  41 30  connects  remote 
TCP/IP  networks  over  both  high¬ 
speed  point-to-point  and  X.25 
networks.  An  ACS  4130  can  be 
used  to  link  the  X.25  network  with 
remote  hosts,  or  to  interconnect 
other  ACS  41 30s  through  private  or 
common  X.25  carriers. 

By  simultaneously  using  point-to- 
point  on  one  serial  link,  and  X.25  on 
another,  the  ACS  4130  creates  a 
dynamic,  redundant  link  that  serves 
as  a  backup  in  case  of  failure. 


Network  Management,  a  network  administrator  at  a  single  location  can  query  command, 
query  status,  and  receive  responses  from  any  ACS  4130  in  the  network. 


APPLICATION 


University  Environment 

Faculty,  staff,  and  students  at  speed  fiber  optic  lines  that  also  quickly  and  with  a  greater  degree  of 

one  campus  of  a  statewide  univer-  carry  inter-campus  voice  traffic.  accuracy  than  any  overnight  mail 

sity  system  could  use  ACS  41 30s  to  The  ACS  41 30  routers  could  service  or  even  a  facsimile  machine 

give  them  access  to  resources  in  provide  users  with  access  to  the  could  offer.  Also,  all  the  users 

other  departments  and  also  to  mainframe  resources  they  need.  could  share  one  X.25  port, 

communicate  with  colleagues  at  ACS  41 30s  would  also  give  depart-  Within  the  university  environ- 

other  campuses  via  a  regional  X.25  mental  Ethernets  greater  expansion  ment,  the  ACS  41 30s  would  use 

network  (i.e.,  CERFnet,  NFSnet,  options.  Because  with  routers,  RIP  packets  to  broadcast  routing 

NYSERnet).  individual  LANs  can  create  their  and  addressing  data.  When  a 

Each  department  has  at  least  own  addressing  scheme  with  no  router  at  a  departmental  LAN 

one  Ethernet  LAN  linking  a  variety  fear  of  duplication  by  devices  in  receives  a  packet  bound  for  the 

of  devices.  The  university  also  other  departments.  X.25  net,  it  would  forward  it  to  a 

maintains  a  central  mainframe  ACS  4130s  would  also  allow  router  at  the  computer  center.  This 

system  to  store  student  records,  colleagues  on  separate  campuses  router  would  use  the  External 

financial  accounts,  and  other  data  who  are  conducting  joint  research  Gateway  Protocol  (EGP)  to  gather 

and  applications  pertinent  to  the  to  communicate  over  X.25-based  routing  information  from  the  X.25 

entire  campus.  The  various  sys-  networks.  Documents  could  be  network  and  forward  the  packet  to 

terns  are  interconnected  using  high-  reviewed  and  returned  much  more  the  appropriate  destination. 
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APPLICATION 


Manufacturing  Environment 

A  multi-national  manufacturing 
company  can  use  ACS  41 30  IP 
routers  to  integrate  a  variety  of 
computing  environments.  Creating 
*  this  internetwork  enhances  effi¬ 
ciency  throughout  the  corporation. 
With  routers,  users  in  different 
corporate  entities  can  have  direct 
,  and  immediate  access  to  the 
information  they  need  to  do  their 
jobs. 

Instead  of  a  central  computer 
system,  information  system  re¬ 
sources  are  distributed  throughout 
the  company.  Each  department 
chooses  the  hardware  and  software 
best  suited  to  its  particular  needs. 
With  the  common  factors  of  Eth¬ 


ernet  LANs  running  TCP/IP,  this 
combination  of  systems  from  many 
vendors  could  easily  be  linked 
together  with  ACS  4130  routers. 

Since  there  are  no  connections 
to  any  public  networks,  the  ACS 
4130s  would  use  Routing  Informa¬ 
tion  Protocol  (RIP)  to  broadcast 
routing  information  to  other  routers 
in  the  internetwork. 

Sales  orders  and  forecasting 
data  could  be  collected  from  inter¬ 
national  and  domestic  sales  offices 
and  combined  into  a  single  report 
for  manufacturing.  Because 
manufacturing  would  have  informa¬ 
tion  that  is  current  and  comprehen¬ 
sive,  it  could  process  orders  more 


quickly  and  maintain  inventories  at 
optimal  levels. 

At  headquarters,  finance  people 
could  combine  sales  order  reports 
and  manufacturing's  production 
schedules  to  prepare  accounts 
receivables.  At  a  separate  facility, 
engineering  could  download  the 
test  procedures  manufacturing 
needs  to  maintain  quality  control. 

With  ACS  4130s,  the  company 
could  protect  proprietary  information 
and  resources  from  unauthorized 
use.  IP  security  could  be  used  to 
prevent  access  to  resources  such 
as  proprietary  R&D  information  in 
engineering  and  payroll  accounts  in 
finance. 


Corporate  Sales 
And  Headquarters 
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ACC  Customer  Service 

ACC  is  committed  to  providing 
customers  with  comprehensive 
support  and  service  that  will  help 
them  get  the  most  from  ACC’s  data 
communications  products. 

Our  experienced  support  person¬ 
nel  are  readily  available  to  answer 
your  questions  long  after  the 
purchase  is  complete. 


ACS  4130  Warranty 

ACS  4130  software  and  hard¬ 
ware  are  warranted  for  90  days. 
After. this  period,  ACS  4130  cus¬ 
tomers  can  benefit  from  subscribing 
to  Service  One,  ACC’s  extended 
warranty  plan  which  includes: 

•  Telephone  Hotline.  Experienced 
product  support  and  technical 
specialists  answer  your  ques¬ 
tions  by  phone  during  regular 
business  hours. 


♦  Problem  Fixes  and  Software 
Enhancements. 

•  Updated  Software  Releases  and 
corresponding  documentation. 

In  addition.  Service  One  custom¬ 
ers  benefit  from  the  ACS  4130’s 
SNMP.  Since  ACC’s  customer 
service  systems  also  support 
SNMP,  our  technicians  can  re¬ 
motely  access  your  ACS  4130 
system  to  troubleshoot  faults  right 
from  their  desks. 


Specifications 

Power  Requirements 

AC  Voitage:  90  to  132  Vac,  180  to  264  Vac 

Frequency:  47  to  63  Hz 

Power  Consumption:  100  Watts  maximum 

Operating  Environment 

Temperature:  5^  to  4(JP  C  (41°  to  104°  F) 

Humidity:  20%  to  80%  non-condensing 

Physical  Dimensions 

Size:  3.5''Hx  12.5"D  x  17.5"W 

Weight:  11  lbs. 

Serial  Line  Interfaces  Two  ports,  any  combination 

V.35  34-pin  male  connectors 
RS-422/449  DB  37-pin  male  connectors 
RS-232  DB  25-pin  male  connectors 
RS-530  DB  25-pin  male  connectors 


Console  Ports 

One  male  RS-232  DTE  connector 

One  female  RS-232  DCE  connector 

Network  Interfaces 

One  port,  either  option 

Standard  Ethernet  (1 0BASE5)  802.3 

Thinwire  Ethernet  (10BASE2)  802.3 

RFCs  Supported 

RFC  768  (UDP),  RFC  791  (IP),  RFC  792  (ICMP),  RFC  796  (AdMap),  RFC  826  (ARP), 
RFC  904  (EGP),  RFC  950  (Subnet),  RFC  1009  (Internet  Gateway),  RFC  1058  (RIP), 
RFC  1065  (SMI),  RFC  1066  (MIB),  and  RFC  1067  (SNMP) 

Advanced  Computer 
Communications 


720  Santa  Barbara  Street 
Santa  Barbara.  CA  93101 
TWX  910  334-4907 
Fax  (805)962-8499 
Telephone  (800)444-7854 


East  Coast  Office 
10220  Old  Columbia  Road 
Columbia,  MD  21046 
Telephone  (301)290-8100 
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Founded  in  1984  by  Leonard  Bosack  and  Sandy  Lerner. 
cisco  Systems.  Inc.  manufactures  and  markets  high- 
performance.  multimedia  and  multiprotocol  internetwork 
gateways  and  terminal  servers.  The  company  s  gateway 
technology  can  be  used  to  build  wide-area  networks  that 
link  an  unlimited  number  of  geographically  dispersed 
LA.Ns  and  to  provide  router  throughput  of  up  to  12.000 
packets  per  second.  The  internetworking  products  of  cisco 
facilitate  the  construction  of  large,  complex,  local-,  and 
wide-area  networks  based  on  multivendor  and  multipro¬ 
tocol  computing  equipment.  Protocols  supponed  by  cisco 
products  include  Transmission  Control  Protocol/Internet 
Protocol  (TCP/IP).  X.:5,  DECnet.  XNS.  Chaosnet,  and 
OSI.  The  company  categorizes  its  product  line  as  internet¬ 
work  routers  (gateways),  internetw'ork  bridge/ router  com¬ 
binations.  and  terminal  servers. 

The  cofounders  of  the  company  participated  in  the  devel¬ 
opment  and  implementation  of  an  internetwork  based  on 
the  TCP/IP  protocol  at  Stanford  University,  where  Bo¬ 
sack  serx'ed  as  Director  of  Computer  Facilities  for  the 
Computer  Science  Department,  and  Lerner  periormed 
those  tasks  for  the  Graduate  School  of  Business.  Under 
Bosack* s  direction.  Stanford  became  one  ot  the  first  im- 
plementers  of  the  TCP/IP  standard  in  1982.  culminating 


Cisco  Systems  jamily  of  token  ring  internetw  ork  routers  and 
terminal  servers  are  based  on  the  firm  s  Token  Rine  interface 
card,  w  hich  provides  a  connection  to  token  ring  *IEEE  SO^.2) 
networks  running  at  speeds  up  to  four  megabits  per  second. 


i  VENDOR:  cisco  Systems.  Inc.,  1360  Willow 
I  Road.  Menlo  Park.  California  94025.  Telephone 
1  (415)326-1941. 

I  CANADIAN  DISTRIBUTION:  Granville  Technolo¬ 
gies.  Toronto  M5T  3A3.  Telephone  (416)  977- 
6902. 

PRODUCTS:  Four-member  family  of  internet- 
i  work  routers  and  terminal  servers:  Gateway 
I  Servers:  STS-1 0  terminal  server:  TRouter  TCP/IP 
terminal  server  and  multiprotocol  internetwork 
router:  HyBridge  hybrid  bridge/router. 

;  COMPETITION:  Banyan  Systems.  Halley  Sys- 
j  terns.  Honeywell  Bull.  3Com,  Wellfleet  Commu¬ 
nications. 

PRICE:  See  Equipment  Prices  for  detailed  list¬ 
ings. 
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work  begun  almost  two  decades  earlier  under  the  sponsor¬ 
ship  of  the  Defense  Depanment  s  -Xdvancec  Research 
Projects  Agency  cDARPA). 

TCP/IP  has  evolved  into  a  mature  protocol  suite  sup¬ 
ported  by  major  computer  vendors  and  operating  in  many 
networks  including  ARPAnet.  TCP  IP  protocols  are  me¬ 
dium  independent  and  widely  implemented  on  commer¬ 
cial  networks  of  all  media  types.  Equipment  from  cisco 
works  with  all  vendor  TCP/IP  implementations.  The 
company  is  continuing  to  make  enhancements  to  us  TCP^ 
IP  software  base. 

As  the  basis  of  its  internetworking  technology,  cisco  uses 
the  Interior  Gateway  Routing  Protocol  (IGRP).  for  which 
it  has  a  patent  pending.  IGRP  is  a  technique  devised  for 
automatic  packet  routing  and  Ilow  optimization,  which 
eliminates  the  need  for  static  or  manual  routing  tables  that 
are  used  by  other  network  equipment  to  determine  rout¬ 
ing  pathways.  IGRP  furnishes  dynamic  internetwork  rout¬ 
ing,  which  automatically  adjusts  to  changes  in  network 
topology  or  status.  This  technology  bypasses  the  time- 
consuming.  error-prone  manual  network  tasks  associated 
with  other  methods  of  routing.  In  addition.  IGRP  calcu¬ 
lates  in  realtime  within  the  gateway  itself  the  following 
events:  delay,  packet  type,  actual  tratTic.  error  rates,  and 
security. 
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The  product  strategy  espoused  by  cisco  calls  for  the  full 
implementation  of  each  of  the  OSI  modefs  protocols  after 
they  are  formalized  by  the  ISO.  The  company's  approach 
has  always  been  to  base  its  products  on  TCP/IP.  which 
suppons  internetworking  at  this  lime  and- will  also  inter¬ 
operate  with  ISO-specified  protocols  in  the  future.  The 
company  is  also  conducting  research  and  engineering 
projects  on  Fiber  Distributed  Data  Interface  (FDDI)  and 
ISDN. 

All  cisco  products  connect  to  X.25.  which  forms  the  basis 
for  most  public  data  networks.  The  products  connect  to 
Telenet.  Tymnet,  and  ATiT’s  Accunet  m  the  United 
Slates.  Public  data  networks  outside  the  United  States 
accessed  by  cisco  products  include  Datapac  in  Canada; 
PSS.  X.25  Kilostream  and  Megasiream  in  the  United 
Kingdom:  Daie.\-P  in  West  Germany:  and  TRANSPAC  in 
France. 

This  young  company  offers  a  wide  selection  of  internet¬ 
working  products,  among  which  are  gateway  servers,  a 
four-member  family  of  internetwork  routers  and  terminal 
ser\'ers:  STS- 10  terminal  sen'er.  TRouier  TCP/IP  termi¬ 
nal  server  and  multiprotocol  internetwork  router:  Hy- 
Bridge  hybrid  bridge/rouier:  cisco  Token  Ring  Interface: 
and  cisco  .Multiport  Communications  Interface  Board. 


PRODUCT  EVALUATION 

One-stop  shopping  for  all  LAN  needs  aptly  describes  the 
product  line  of  cisco  Systems.  The  terminal  ser\  ers  from 
cisco  can  multiplex  data  from  RS-232  serial  lines  and 
parallel  I/O  ports  onto  their  high-speed  network  inter¬ 
faces.  Each  terminal  line  suppons  data  rates  up  to  38. 4K 
bps.  while  providing  rotary  and  modem  functions. 

P.ADs  trom  cisco  can  furnish  up  to  96  devices  with  direct 
connections  to  public  packet-switched  networks  or  the 
Defense  Data  Networks,  via  X.25.  X.3.  X.2S.  and  X.29 
protocols.  The  P.ADs  suppon  data  transfer  rates  to  the 
network  trom  2,4K  bps  to  1500K  bps.  They  also  provide 
all  the  capabilities  of  cisco  terminal  ser\  ers. 

The  company  otTers  Terminal  Access  Controllers  (T.ACs) 
that  can  provide  up  to  96  devices  with  direct  connections 
to  the  Defense  Data  Network  via  the  DDN  X.25  standard. 
DDN-DH/LH.  or  DDN-HDH  connection  methods.  The 
TACs  multiplex  serial  lines  and  parallel  pons  at  data  rates 
up  to  38. 4K  bps  with  security  on  a  per-Iine  basis.  The 
Defense  Communications  Agency  has  certified  cisco 
TACs  for  attachment  to  the  Defense  Data  Network. 

SLIP  sencrs  from  cisco  can  send  and  receive  IP  packets 
with  personal  computers  or  workstations  that  run  under 
MS-DOS.  SLIP  software  combines  with  cisco  terminal 
sen  ers  to  provide  full-function  network  file  transfer  ser¬ 
vices  to  personal  computers. 


The  terminal  serx'ers.  PaDs.  and  TACs  from  cisco  enable 
users  to  share  high-quality  printers  and  plotters  over  the 
entire  LAN. 

Gatcnav  Servers:  cisco  gateway  servers  are  dynamic,  high- 
performance.  intelligent  internetwork  routers  and  gate¬ 
ways  that  send  each  segment  of  the  network  only  those 
messages  destined  for  it.  a  feature  that  avoids  unnecessarv 
traffic  and  eliminates  broadcast  storms.  Users  of  cisco  s 
communications  and  gateway  ser\'ers  can  construct  large, 
complex  local-  and  wide-area  networks  that  support  inter¬ 
network  communication  for  thousands  of  subnets  and 
hundreds  of  thousands  of  host  computers. 

Based  on  the  .Motorola  68000  or  68020  microprocessor, 
cisco  gateway  sen*ers  suppon  Ethernet,  serial,  and  token¬ 
ring  network  channel  interfaces  and  provide  software  con¬ 
nections  through  these  interfaces  to  DDN  .\.25  and  PSN 
.X.25  networks.  Gatew'ays  from  cisco  can  perform  m  fiber 
optic  networks  because  the>  dynamically  recognize  and 
draw  ‘upon  network  segments  with  faster  transmission 
bandwidths.  The  company's  gateways  enable  organiza¬ 
tions  to  construct  WANs  that  include  major  existing  net¬ 
works  such  as  BITNET  and  CSnei  (Defense  Data 
Network).  NSF  regional  networks  such  as  JVNCnet  and 
WESTnet.  and  public-packet  switched  network  services 
such  as  Telenet.  Tymnet,  and  TR.A.NSPAC. 

In  Apnl  1 989.  cisco  announced  it  was  offering  support  for 
.Apple  Computer's  .AppleTalk  network  protocol  through 
its  famiiy  of  internetwork  routers  used  exclusively  in 
wide-area  network  installations,  .All  cisco  routers  shipped 
after  March  will  otTer  AppieTalk  running  concurrently 
with  other  protocols  at  no  extra  cost.  AppieTalk  routing  is 
supported  over  cisco's  Ethernet  (IEEE  302.3).  synchro¬ 
nous  serial,  token  ring  (IEEE  802.5).  and  .X.25  network 
interfaces.  The  incorporation  of  AppieTalk  into  cisco's 
repertoire  of  concurrently  supponed  protocols  addresses 
the  problem  of  the  increasing  number  of  .Macintoshes 
being  attached  to  multiple  Ethernet  LANs  within  a  user 
installation. 

Macintosh  users  will  receive  the  full  benefits  of  routers 
from  cisco's  suppon  of  AppieTalk.  These  routers  penorm 
network-level  switching  and  can  isolate  subnetworks  of 
Media  .Access  Control  i.M.AC)  to  protect  them  against 
noise  and  broadcast  storms.  This  type  of  network  segmen¬ 
tation  can  also  overcome  AppleTalk's  basic  limit  of  254 
nodes  per  Ethernet.  Services  provided  by  cisco's  imple¬ 
mentation  of  AppieTalk  include  Routing  Table  .Manage¬ 
ment  Protocol  (RTMP).  .Name  Binding  Protocol  (NBP). 
Echo  Protocol  (EP).  AppieTalk  Transaction  Protocol 
(ATP),  and  Zone  Information  Protocol  (ZIP). 

Internetwork  Routers  and  Terminal  Servers:  In  this  four- 
member  family,  cisco  has  incorporated  capabilities  of  pro¬ 
viding  connections  to  token-ring  (IEEE  802.5)  local  area 
networks.  This  new  line  includes  a  token-ring  terminal 
server  that  suppons  up  to  96  devices:  a  token-nng-to- 
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Ethernet  (IEEE  802.3)  router  a  token-ring-to-ioken-ring 
router  and  a  token-ring-to-wide-area  network  router  using 
synchronous  serial  lines.  The  four  products  are  based  on 
cisco's  new  Token  Ring  Interface  card,  which  offers  a 
connection  to  token-ring  networks  operating  at  speeds  up 
to  four  megabits  per  second.  Like  ail  cisco  serv'ers,  the 
token-ring  units  suppon  multiple,  concurrently  running 
protocols,  including  the  Depanment  of  Defense  standard 
TCP/IP,  Xerox  Network  Systems  (XNS).  Digiiafs  DEC- 
net,  and  X.25. 

According  to  John  Morgridge,  cisco  president,  the  new 
product  line  “addresses  a  growing  corporate  need  to  pro¬ 
vide  connectivity  for  entire  organizations,  to  fully  inte¬ 
grate  the  engineering  networks  and  the  PC  work  groups 
which  formerly  existed  as  islands  of  communication.  Our 
new  products  let  such  organizations  take  full  advantage  ot 
the  diverse  transmission  media  that  coexist,  including 
token-ring.  Ethernet,  and  synchronous  serial  lines  up  to 
TI  speeds.'* 

One  of  the  principal  advantages  offered  by  the  cisco  rout¬ 
ers  is  the  elimination  of  the  many  backbone  networks  that 
users  must  support  if  they  want  to  run  multiple  protocols 
over  a  wide-area  network.  Routers  from  cisco  that  are 
placed  at  either  end  of  a  synchronous  serial  backbone 
linking  two  sites  let  the  user  dispense  with  insiailing  sepa¬ 
rate  and  costly  backbones  for  each  protocol  run. 

Routers  can  also  combine  network  types  in  diverse  config¬ 
urations.  such  as  connecting  two  token  rings  over  an 
Ethernet  or  serial  backbone,  or  linking  a  combination  oi 
Ethernets  and  token  rings  over  an  X.25  wide-area  net¬ 
work. 


vide  service  to  a  remote  Ethernet  via  a  synchronous  serial 
line  at  rates  ranging  from  9.6K  bps  to  TI.  For  remote 
access  to  the  network,  users  can  attach  asynchronous  dial- 
in  and  dial-out  modems  to  the  senai  pons.  Via  an  X.25 
data  network,  users  can  set  up  TRouter  at  a  remote  office 
to  connect  to  other  remote  offices. 

HyBrid^e:  HyBridge.  cisco's  hybrid  bridge/rouier.  per¬ 
forms  simultaneous  bridging  and  routing  functions  on  the 
same  network.  When  acting  as  a  bridge  or  a  router.  Hn- 
Bridge  can  switch  12.000  packets  per  second.  The  chiei 
advantage  of  using  a  multiprotocol  h\  brid  bridge/ gaiewav 
product  like  HyBridge  is  its  ability  to  link  many  kinds  or 
computers  and  network  technologies  without  the  use  ot 
different  protocol-specific  or  meaium-speciilc  routers. 
Since  HyBridge  merges  bridging  and  routing  firmware.  :is 
networks  provide  secure  and  reliable  gateway-based  inter¬ 
network  systems.  In  addition,  the  user-selectable  features 
of  HyBridge  enable  users  to  preserv  e  their  investments  m 
LAN  technology  because  they  do  not  have  to  replace 
existing  equipment  to  attain  internetwork  connectiviu. 
The  product  otTcrs  users  a  growth  path  to  large  LANs  and 
WANs. 


MARKET  POSITION 

Responding  to  the  need  to  interrelate  various  s\  stems, 
cisco  has  been  moving  for^vard  ever  since  its  founding. 
The  company  has  staked  out  a  niche  in  the  interneiworK- 
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STS-IO  Terminal  Server:  The  STS- 10  server  provides  con¬ 
nection  for  up  to  lO  asynchronous  devices  to  an  Ethernet 
(IEEE  802.3)  LAN  running  the  TCP/IP  network  protocol 
set.  Placed  at  the  low  end  of  cisco's  terminal  serv*er  line, 
the  STS-10  offers  connectivity  for  multivendor  terminals, 
printers,  and  other  resources  for  users  w’ith  geographically 
dispersed  or  departmentalized  groupings.  The  STS- 10 
originated  from  cisco’s  addition  of  terminal  serx  er  soft¬ 
ware  to  a  hardware  product  purchased  from  Communica¬ 
tion  Machinery*  Corporation  of  Santa  Barbara.  California, 
under  an  OEM  agreement.  The  multiple  session  feature  of 
the  STS-10  allows  the  terminal  to  open  and  facilitate 
switching  among  multiple  remote  connections. 

TRouter:  cisco  has  introduced  TRouter.  the  first  network 
device  that  combines  multiprotocol  internetwork  routing 
and  TCP/IP  terminal  service.  This  multifunction  device 
addresses  the  needs  of  small  work  ^oups  that  require  both 
terminal-server  and  packet-switching  functions.  TRouter 
provides  an  economical  method  for  small-  or  medium¬ 
sized  work  groups  to  attain  LAN  or  WAN  access  and  also 
connectivity  for  modems,  printers,  and  PCs  without  hav¬ 
ing  to  purchase  a  terminal  server  and  a  router.  Users  can 
place  TRouter  on  the  periphery  of  their  networks  to  pro- 
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AGGREGATE  BANDWIDTH  OF  THE  FUTURE 
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STANDARDS  INFORMATION 


CCtTT  Series  Recommendations 


Number  _ Title  _ 

V.1  Equivalence  between  binary  notation  symbols  and  the  significant 

conditions  of  a  two-condition  code. 

V.2  Power  levels  for  data  transmission  over  telephone  lines. 

V.3  international  Alphabet  No.  5. 

V.4  General  structure  of  signals  of  Internatbnal  Alphabet  No.  5  code  for  data 

transmission  over  public  telephone  networks. 

V.5  Standardization  of  data  signaling  rates  for  synchronous  data 

transmission  in  the  general  switched  telephone  network. 

V.6  Standardization  of  data-signaling  rates  for  synchronous  data 

transmission  on  leased  telephone  -type  circuits. 

V.7  Definitions  of  terms  concerning  data  communication  over  the  telephone 

network. 


V.10(X.26)  Electrical  characteristics  for  unbalanced  double-current  interchange 

circuits  for  general  use  with  integrated  circuit  equipment  in  the  field  of 
data  communications. 

V.11(X.27)  Electrical  characteristics  for  balanced  double-current  interchange 

circuits  for  general  use  with  integrated  circuit,  equipment  in  the  field 
of  data  communications. 

V.1 5  Use  of  acoustic  coupling  for  data  transmission. 

V.  1 6  Medical  analogue  data  transmission  modems. 

V.1 9  Modems  for  parallel  data  transmission  using  telephone  signaling 

frequencies. 

V.20  Parallel  data  transmission  modems  standardized  for  universal  use  in  the 

general  switched  telephone  network. 

V.21  300  bits  per  second  duplex  modem  standardized  for  use  in  the  general 

switched  telephone  network. 

V.22  1200  bits  per  second  duplex  modem  standardized  for  use  on  general 

switched  telephone  network  and  on  leased  circuits. 


CCITT  Series  Recommendations 


Number 


Title 


V.23 

V.24 

V.25 

y.26 

V.26bis 

V.27 

V.27bis 

V.27ter 

V.28 


600/1 200-baud  modem  standardized  for  use  in  the  general  switched 
telephone  network. 

List  of  definitions  for  interchange  circuits  between  data  terminal 
equipment  and  data  circuit-terminating  equipment. 

Automatic  calling  and/or  answering  equipment  on  the  general  switched 
telephone  network,  including  disabling  of  echo  suppressors  on 
manually  established  calls. 


2400  bits  per  second  modem  standardized  for  use  on  four-wire  leased 
circuits. 


2400/1200  bits  per  second  modem  standardized  for  use  in  the  general 
switched  telephone  network. 

4800  bits  per  second  modem  with  manual  equalizer  telephone-type 
circuits  standardized  for  use  on  leased  circuits. 

4800/2400  bits  per  second  modem  with  automatic  equalizer 
standardized  for  use  on  leased  telephone-type  circuits. 

4800/2400  bits  per  second  modem  standardized  for  use  in  the  general 
switched  telephone  network. 

Electrical  characteristics  for  unbalanced  double-current  interchange 
circuits. 


9600  bits  per  second  modem  standardized  for  use  on  point-to-point 
four-wire  leased  telephone  type  circuits. 

Electrical  characteristics  for  single-current  interchange  circuits 
controlled  by  contact  closure. 

Data  transmission  at  48  kilobits  per  second  using  60-108  kHz  arouo 
band  circuits.  ^ 


Modems  for  synchronous  data  transmission  using  60-108  kHz  orouo 
band  circuits. 


CCITT  Series  Recommendations 


Number 

V.37 

V.40 

V.41 

V.50 

V.51 

V.52 

V.53 

V.54 

V.55 

V.56 

V.57 

X.1 

X.2 

X.3 

X.4 

X.15 

X.20 

X.20bis 


_ Title _ 

Synchronous  data  transmission  at  a  data  signaling  rate  higher  than  72 
kbits  using  60-108  kHz  group  and  circuits. 

Error  indication  with  electromechanical  equipment. 

Code  independent  error  control  system. 

Standard  limits  for  transmission  quality  of  data  transmission. 

Organization  of  maintenance  of  international  telephone  type  circuits 
used  for  data  transmission. 

Characteristics  of  distortion  and  error-rate  measuring  apparatus  for 
data  transmission. 

Limits  for  the  maintenance  of  telephone-type  circuits  used  for  data 
transmission. 

Loop  test  devices  for  modems. 

Specification  for  an  impulse  noise  measuring  instrument  for  telephone- 
type  circuits. 

Comparative  tests  for  modems  for  use  over  telephone-type  circuits. 

Comprehensive  data  test  set  for  high  data  signaling  rates. 

International  user  classes  of  service  in  public  data  networks. 

International  user  services  and  facilities  in  public  data  networks. 

Packet  assembly/disassembly  facility  (PAD)  In  a  public  data  network. 

General  structure  of  signals  of  International  Alphabet  No.  5  code  for  data 
transmission  over  public  data  networks. 

Definitions  of  terms  concerning  public  data  networks. 

Interface  between  data  terminal  equipment  (DTE)  and  data  circuit¬ 
terminating  equipment  (DCE)  for  start-stop  transmission  services  on 
public  data  networks. 

Use  on  public  data  networks  of  data  terminal  equipment  (DTE)  which  is 
designed  for  interfacing  to  asynchronous  duplex  V-series  modems. 


X.21bis 


X.22 

X.24 


X.26(V.10) 


X.27(V.11) 


X.29 


X.SObis 


Interface  between  data  terminal  equipment  (DTE)  and  data  circuit- 
netwofks  ^  equipment  (DCE)  for  synchronous  operation  of  public  data 

*^3*3  terminal  equipments  which  is 
designed  for  interfacing  to  synchronous  V-series  modems. 

Multiplex  DTE/DCE  interface  for  user  classes  3-6. 

'[J®;change  circuits  between  data  terminal 
Sblte  daL  ?eiS>fe  arcuit-lerminating  equipment  (DCE)  on 

toll'SS  between  data  terminal  equipment  (DTE)  and  data  circuit- 
terminating  equipment  (DCE)  for  terminals  operating  In  the  packet 
made  on  public  data  networks. 

Electrical  characteristics  for  unbalanced  double-current  Inlerchanoe 

Su  S,J,muSlns““  »' 

Electrical  characteristics  for  balanced  double-current  Interchanoe 

StaSmlSlr  «’*  «' 

Sg  'ras\rbi^d?s^^^^^ 

data  network  situated  in  the  same  country.  ^ 

^ocedures  for  the  exchange  of  control  information  and  user  data 

modulated  transmission  systems 
a  group^  telegraph  and  data  channels  by  frequency  division  of 

Fundamental  parameters  of  a  multiplexing  scheme  for  the  international 
interface  between  synchronous  data  networks. 

Fundamental  parameters  of  a  48  kbIt/s  user  data  signalinq  rate 
transmission  scheme  for  the  International  interface  between 
synchronous  data  networks. 


CCITT  Series  Recommendations 


Number 

X.51 

X.SIbis 

X.52 

X.53 

X.54 

X.60 

X.61 

X.71 

X.75 

X.80 

X.87 

X.92 

X.96 

X.110 

X.121 

X.130 

X.132 


Title 


Fundamental  parameters  of  a  multiplexing  scheme  for  the  international 
interface  between  synchronous  data  networks. 

Fundamental  parameters  of  a  48  kbIt/s  user  data  signaling  rate 
transmission  scheme  for  the  international  interface  between  syn¬ 
chronous  data  networks  using  10-bit  envelope  structure. 

Method  of  encoding  anisochronous  signals  into  a  synchronous  bearer. 

Numbering  of  channels  on  international  multiplex  links  at  64  kbit/s. 

Allocation  of  channels  on  international  multiplex  links  at  64  kbit7s. 

Common  channel  signaling  for  circuit  switched  data  applications. 

Signaling  system  No.  7-  Data  user  part. 

Decentralized  terminal  and  transit  control  signaling  system  on 
international  circuits  between  synchronous  dat  networks. 

Terminal  and  transit  call  control  procedures  and  data  transfer  system 
on  international  circuits  between  packet-switched  data  networks. 

interworking  of  interexchange  signaling  systems  for  circuit  switched 
data  services. 

Principles  and  procedures  for  realization  of  international  user 
facilities  and  network  utilities  in  public  data  networks. 

Hypothetical  reference  connections  for  public  synchronous  data 
networks. 

Call  progress  signals  in  public  data  networks. 

Routing  principles  for  International  public  data  services  through 
switched  public  data  networks  of  the  same  type. 

International  numbering  plan  for  public  data  networks. 

Provisional  objectives  for  call  set-up  and  clear-down  times  in  public 
synchronous  data  networks  (circuit  switching). 

Provisional  objectives  for  grade  of  service  In  international  data 
communications  over  circuit  switched  public  data  networks. 


C.CITT  Series  Recommendations 

Niimbgr _ Title 

X.150 


X.180 


DTE  and  DCE  test  loops  in  public  data  networks. 

J^^^^jstrative  arrangements  for  International  closed  user  groups 


International  Organization  for  Standardization 


Number 

ISO  646 

ISO  1155 

ISO  1177 

ISO  1745 
ISO  2022 

ISO  2110 

ISO  21 1 1 
ISO  2593 
ISO  2628 
ISO  3309 
ISO  4335 

ISO  4902 

ISO  4903 

ISO  6159 
ISO  6256 


ims. 


Seven-bit  character  set  for  information  processing  interchange- 
1973,  confirmed  1979. 

Information  processing  -  Use  of  longitudinal  parity  to  detect  errors  in 
information  messages  -  1978. 

Information  processing  -  Character  structure  for  start/stop  and 
synchronous  transmission  -  1973,  revision  being  balloted. 

Information  processing  -  Basic  mode  control  procedures  for  data 
communications  systems  -  1 975,  revision  being  balloted. 

Code  extension  techniques  for  use  with  ISO  seven-bit  coded  character  set 
-  1973. 

Data  communications  -  25  pin  DTE/DCE  interface  connector  and  pin 
assignments  •  1980. 

Data  communication  -  Basic  mode  control  procedures  •  Code 
independent  Information  transfer  -  1972.  revision  being  balloted. 

Connector  pin  allocations  for  use  with  high  speed  data  terminal 
equipment  •  1973,  revision  being  balloted. 

Basic  mode  control  procedures  •  Complements  -  1973,  confirmed 
1979. 

Data  communication  -  High  level  data  link  control  procedures-  frame 
structure  -  1979,  revision  being  balloted. 

Data  communication  -  High  level  data  link  control  procedures  - 
Elements  of  procedures  1979  -  Addendum  1,  1979;  Addendum  11, 

1981. 

Data  communication  -  37-pin  DTE/DCE  interface  connector  and  pin 
assignments  •  1980. 

Data  communication  -  15-pin  DTE/DCE  interface  connector  and  pin 
assignments  •  1980. 

Data  communication  •  HDLC  unbalanced  classes  of  procedures  -  1980. 
Data  Communication  -  HDLC  balanced  class  of  procedures  -  1 980. 


X3. 1-1976 
X3. 4-1977 


X3. 15-1976 


X3. 16-1976 


X3.24 


X3.25  -  1976 


X3. 28-1976 


X3. 36-1975 


X3. 41-1974 


X3. 44-1974 
X3. 57-1  977 


X3. 66-1979 
X3. 79-1981 


Synchronous  signaling  rates  for  data  transmission. 

Code  for  information  Interchange. 

Bit  sequencing  of  the  American  National  Standard  Code  for  information 
interchange  in  serial-by-bit  data  transmission. 

structure  and  character  parity  sense  for  serial-by-bit  data 
interchange'^"  National  Standard  Code  for  information 

Signal  quality  at  interface  between  data  terminal  equipment  and 

fadStTnf  DC  tor  serial  data  transmission 

(adopts  EIA  RS-334-A)  -  pending  resolution  of  negative  ballot. 

'  Character  structure  and  character  parity  sense  for  parallel  by-bit 
Interchange*^"  '"  National  Standard  Code  for  Information 

Procedures  for  the  use  of  communication  control  characters  of 
American  National  Standard  Code  for  Information  Interchange  in 
specified  data  communication  links. 

Ngh-speed  data  signaling  rates  between  data  terminal 
equipment  and  data  communication  equipment. 

^e  extension  techniques  for  use  with  7  bit  coded  character  set  of 
American  National  Standard  CJode  for  Information  Interchange. 

Determination  of  the  performance  of  data  communication  systems. 

oMormattlng  message  headings  for  information  interchange 

for  J  tor  information  interchange 

tor  data  communication  system  control.  * 

For  advanced  data  communications  control  procedures  (ADCCP). 

S?  performance  of  data  communication  systems  that  use 

bit-oriented  procedures. 


X3. 92-1 981  Data  encryption  algorithm. 


Several  other  organizations  are  quite  active  in  the  standards  area. 
The  European  Computer  Manufacturers  Association  (ECMA)  has 
published  some  valuable  documents  on  HDLC  and  local  area  networks 
(ECMA,  114  Rue  du  Rhone,  CH-1204  Geneva,  Switzerland).  The 
Electronics  Industries  Association  has  many  published  standards  and 
provides  a  catalog  of  these  documents  (ELA,  2001  Eye  St.,  N.W., 
Washington,  D.C.  20006).  The  National  Communications  System 
(NCS),  (General  Services  Administration,  Specification  Distribution 
Board,  Building  197,  Washington  Navy  Yard,  Washington,  D.  C.  20407) 
and  the  National  Bureau  of  Standards  (write  to  the  NTIS)  publish 
standards  for  government  organizations. 


NTT'S  STANDARDS 


Ethernet 
Token  Ring 


X.25 

Telnet 

RPC 


ISO 

Internet 

OSF 


TCP/IP 

X.400 

FTAM 

SMTP 

SNMP 

OSI  Network  Management 

FTP 

OSI  TP 

UDP 


III  -  human  user  interface 


OSF/Motif 
Open  Look 

Presentation  Manager 


Internet 

ISO 

ISO 

ISO 

Internet 

ISO 

Internet 

ISO 

Internet 


OSF 

Ul 

Microsoft 

IBM 

ISO 


Elements  of  these  networking  standards  are  at  the  core  of  NTT  s  MIA. 


V  -  SERIES  STANDARDS 


X.20  bis 

Asynchronous  for  V  series 

X.21  bis 

Synchronous  for  V  series 

V.21 

300  bps  switched  lines 

V.22 

1200  bps  leased  lines 

V.22  bis 

2400  bps  switched  lines 

V.23 

300/1200  bps  switched  lines 

V.26 

2400  bps  leased  lines 

V.26  bis 

2400/1200  bps  switched  lines 

V.26  ter 

2400  bps  switched  or  leased  lines 

V.27 

4800  bps  manual  equalizer,  leased  lines 

V.27  bis 

4800/2400  bps  automatic,  equalizier  leased  lines 

V.27  ter 

4800/2400  bps  switched  lines 

V.29 

9600  bps  leased  lines 

V;32 

9600  bps  switched  lines 

V.35 

48  kbits/s  using  60>  108-kl-lz  bands 

V.25 

Automatic  call  unit 

CCITT  and  Bell/AT&T  Modem  Types 


Modem 

Type 

cxm* 

Sundard 

Transmission 

Mode 

Circuit 

Type 

Sync/ 

Async 

Type  of 
Modulation 

Speed 

(bit/s) 

103J/113D 

V.21 

FDX 

2-W/Dial 

Async 

FSK 

300 

202S 

V.23 

HDX 

2-W/Dial 

As^c 

FSK 

1200 

202T 

V.23 

FDX 

4-W/Leesed 

Async 

FSK 

1200 

212A 

V.22 

FDX 

2-W/Dial 

Async  or  Sync 
or  Sync 

FSK 

2PSK 

300 

1200 

201C 

V.26bis 

FDX 

2-W/4.W 

Dial/Leased 

Sync 

4PSK 

2400 

201B 

V.26 

FDX 

4.W/Lcased 

Sync 

4PSK 

2400 

208A 

V.27bis 

FDX 

4-W/Lcascd 

Sync 

8PSK 

4800 

208B 

V.27ter 

FDX 

2-W/Dial 

Sync 

8PSK 

4800 

209 

V.29 

FDX 

4-W/Lcased 

Sync 

16QAM 

9600 

EIA  and  RELATED  STANDARDS 


SERIES 

RS232-C 

RS269-B 

RS334-A 

RS363 

RS366-A 

RS404 

RS410 

RS422-A 

RS423-A 

RS449 


_ DESCRIPTION _ 

Interface  between  data  terminal  equipment 
and  data  communication  equipment  employing 
serial  binary  data  interchange 

Synchronous  signaling  rates  for  data 
transmission 


Signal  quality  at  interface  between  data 
terminal  equipment  and  synchronous 
data  communication  equipment  for  serial 
data  transmission 

Standard  for  specifying  signal  quality  for 
transmitting  and  receiving  data-processing 
terminal  equipments  using  serial  data 
transmission  at  the  interface  with  non* 
synchronous  data  communication  equipment 

Interface  between  data  terminal  equipment 
and  automatic  calling  equipment  for  data 
communication 

Standard  for  start-stop  signal  quality 
between  data  terminal  equipment  and 
nonsynchronous  data  communication 
equipment 

Standard  for  the  electrical  characteristics 
of  class  A  closure  Interchange  circuits 

Electrical  characteristics  of  balanced 
voltage  digital  interface  circuits 

Electrical  characteristics  of  unbalanced 
voltage  digital  interface  circuits 

General-purpose  37-  and  9-position 
interface  for  data  terminal  equipment  and 
data  circuit-terminating  equipment  employing 
serial  binary  data  interchange 


RELATED  STANDARn.q 

CCITT  V.24.  V.28: 

ISO  2110 

CCITT  V.5,  V.6.  X.1; 

ANSI  X3.1;  FED-STD  1013; 
FIPS  22-1 

ANSI  X3.24 


None 


CCITT  V25 


None 


None 


CCITT  V.11,X.27: 
FED-STD  1020A 

CCITT  V.10,  X.26; 
FED-STD  1030A 

CCITT  V.24,  V.54.  X.21bis 


APPENDIX  F 

GENERIC  ARCHITECTURE  DIAGRAMS 


NTB  NETWORK  Security  Architecture 


Figure  E-1.  NTBN  Architecture  Using  VSLAN.  DISNET  and  CFE®FE  (Source:  H.  Weiss  paper) 
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Figure  E-2.  Applications  for  Verdix  Secure  IP  Router  (Source:  H.  Weiss  paper) 


Figure  E-3.  Verdix  VSLAN  Diagrams  (Source;  Verdix  literature) 


NETWORK  ENVIRONMENT  W/0 
CANEWARE 


\ 


NETWORK  ENVIRONMENT  WITH 
CANEWARE 


NETWORK  ENVIRONMENT  WITH 
CANEWARE  AND  NES 


t«AtA 


Figure  E-5.  CANEWARE  Network  Applications  (Source:  Government  briefing) 


NETWORK  CONSOLIDATION  WITH  CANEWARE 


WAN 


CFE 

^  , 

GATEWAY 


1 

—  \ 

NETWORK 

1  LAN 

MANAGEMENT 


CEE  ■  CANEWARE  FRONT  END 

NFS  •  NETWORK  ENCRYPTION  SYSTEM 

WSA  .  WORKSTATION  SECURITY  APPLIQUE 

EKMS  ■  ELEaRONiC  KEY  MANAGEMENT  SYSTEM  (FIREFLY) 


Figure  E-6.  CANEWARE  and  NES  Network  Applications  (Source:  Government  briefing) 


On-5ite  Connections  to  External  Systems 


TRUSTED  SWITCH 


NETWORK  QUARD 


Figure  E-8.  HFSI  XTS-200  Network  Applications  (Source:  HFSI  literature) 


Controller 


TIU-1 


Figure  E-9.  Wang  TIU  Network  Applications  (Source:  Wang  literature) 
(Note:  Xerox  XEU  applications  are  similar) 


